Managing consistent interfaces for tax authority business objects across heterogeneous systems

ABSTRACT

A business object model, which reflects data that is used during a given business transaction, is utilized to generate interfaces. This business object model facilitates commercial transactions by providing consistent interfaces that are suitable for use across industries, across businesses, and across different departments within a business during a business transaction. In some operations, software creates, updates, or otherwise processes information related to a tax assessment notice, a tax form, a tax object, a tax obligation and/or a tax return business object.

CLAIM OF PRIORITY

This application claims priority under 35 USC §119(e) to U.S. patentapplication Ser. No. 12/323,116, filed on Nov. 25, 2008, the entirecontents of which are hereby incorporated by reference.

TECHNICAL FIELD

The subject matter described herein relates generally to the generationand use of consistent interfaces (or services) derived from a businessobject model. More particularly, the present disclosure relates to thegeneration and use of consistent interfaces or services that aresuitable for use across industries, across businesses, and acrossdifferent departments within a business.

BACKGROUND

Transactions are common among businesses and between businessdepartments within a particular business. During any given transaction,these business entities exchange information. For example, during asales transaction, numerous business entities may be involved, such as asales entity that sells merchandise to a customer, a financialinstitution that handles the financial transaction, and a warehouse thatsends the merchandise to the customer. The end-to-end businesstransaction may require a significant amount of information to beexchanged between the various business entities involved. For example,the customer may send a request for the merchandise as well as some formof payment authorization for the merchandise to the sales entity, andthe sales entity may send the financial institution a request for atransfer of funds from the customer's account to the sales entity'saccount.

Exchanging information between different business entities is not asimple task. This is particularly true because the information used bydifferent business entities is usually tightly tied to the businessentity itself. Each business entity may have its own program forhandling its part of the transaction. These programs differ from eachother because they typically are created for different purposes andbecause each business entity may use semantics that differ from theother business entities. For example, one program may relate toaccounting, another program may relate to manufacturing, and a thirdprogram may relate to inventory control. Similarly, one program mayidentify merchandise using the name of the product while another programmay identify the same merchandise using its model number. Further, onebusiness entity may use U.S. dollars to represent its currency whileanother business entity may use Japanese Yen. A simple difference informatting, e.g., the use of upper-case lettering rather than lower-caseor title-case, makes the exchange of information between businesses adifficult task. Unless the individual businesses agree upon particularsemantics, human interaction typically is required to facilitatetransactions between these businesses. Because these “heterogeneous”programs are used by different companies or by different business areaswithin a given company, a need exists for a consistent way to exchangeinformation and perform a business transaction between the differentbusiness entities.

Currently, many standards exist that offer a variety of interfaces usedto exchange business information. Most of these interfaces, however,apply to only one specific industry and are not consistent between thedifferent standards. Moreover, a number of these interfaces are notconsistent within an individual standard.

SUMMARY

In a first aspect, a tangible computer readable medium includes programcode for providing a message-based interface for performing a taxassessment notice service. The service exposes at least one service asdefined in a service registry. Upon execution, the program code executesin an environment of computer systems providing message-based services.The program code receives, from a service consumer, a first message forprocessing a notice of a tax authority to a taxpayer which states thatthe taxpayer owes taxes or has a refund. The program code invokes a taxassessment notice business object. The business object is a logicallycentralized, semantically disjointed object representing a notice of atax authority to a taxpayer which states that the taxpayer owes taxes orhas a refund. The business object includes data logically organized as atax assessment notice root node and a contract account invoice requestassignment subordinate node. The program code initiates transmission ofa message to a heterogeneous second application, executing in theenvironment of computer systems providing message-based services. Themessage is based on the data in the tax assessment notice businessobject. The message includes a tax assessment notice enterprise resourceplanning message entity, a message header package, a tax assessmentnotice package, and a log package.

In a second aspect, a tangible computer readable medium includes programcode for providing a message-based interface for performing a taxassessment notice service. The service exposes at least one service asdefined in a service registry. Upon execution, the program code executesin an environment of computer systems providing message-based services.The program code initiates transmission of a message to a heterogeneoussecond application, executing in the environment of computer systemsproviding message-based services. The message is based on data in a taxassessment notice business object invoked by the second application. Thebusiness object is a logically centralized, semantically disjointedobject representing a notice of a tax authority to a taxpayer whichstates that the taxpayer owes taxes or has a refund. The business objectincludes data logically organized as a tax assessment notice root nodeand a contract account invoice request assignment subordinate node. Themessage includes a tax assessment notice enterprise resource planningmessage entity, a message header package, a tax assessment noticepackage, and a log package. The program code receives a second messagefrom the second application. The second message is associated with theinvoked tax assessment notice business object and is in response to thefirst message.

In a third aspect, a distributed system operates in a landscape ofcomputer systems providing message-based services. The system processesbusiness objects involving processing a notice of a tax authority to ataxpayer which states that the taxpayer owes taxes or has a refund. Thesystem includes memory and a graphical user interface remote from thememory. The memory stores a business object repository storing aplurality of business objects. Each business object is a logicallycentralized, semantically disjointed object of a particular businessobject type. At least one of the business objects represents a notice ofa tax authority to a taxpayer which states that the taxpayer owes taxesor has a refund. The business object includes data logically organizedas a tax assessment notice root node and a contract account invoicerequest assignment subordinate node. The graphical user interfacepresents data associated with an invoked instance of the tax assessmentnotice business object. The user interface includes computer readableinstructions embodied on tangible media.

In a fourth aspect, a tangible computer readable medium includes programcode for providing a message-based interface for performing a tax formservice. The service exposes at least one service as defined in aservice registry. Upon execution, the program code executes in anenvironment of computer systems providing message-based services. Theprogram code receives, from a service consumer, a first message forprocessing a form that may be filed by the taxpayer or the taxpayer'srepresentative. The program code invokes a tax form business object. Thebusiness object is a logically centralized, semantically disjointedobject representing a form that may be filed by the taxpayer or thetaxpayer's representative. The business object includes data logicallyorganized as a tax form root node, a usage data subordinate node, and aproperty valuation subordinate node. The usage data node contains abilling period subordinate node. The program code initiates transmissionof a message to a heterogeneous second application, executing in theenvironment of computer systems providing message-based services. Themessage is based on the data in the tax form business object. Themessage includes a tax form enterprise resource planning message entity,a message header package, a tax form package, and a log package.

In a fifth aspect, a tangible computer readable medium includes programcode for providing a message-based interface for performing a tax formservice. The service exposes at least one service as defined in aservice registry. Upon execution, the program code executes in anenvironment of computer systems providing message-based services. Theprogram code initiates transmission of a message to a heterogeneoussecond application, executing in the environment of computer systemsproviding message-based services. The message is based on data in a taxform business object invoked by the second application. The businessobject is a logically centralized, semantically disjointed objectrepresenting a form that may be filed by the taxpayer or the taxpayer'srepresentative. The business object includes data logically organized asa tax form root node, a usage data subordinate node, and a propertyvaluation subordinate node. The usage data node contains a billingperiod subordinate node. The message includes a tax form enterpriseresource planning message entity, a message header package, a tax formpackage, and a log package. The program code receives a second messagefrom the second application. The second message is associated with theinvoked tax form business object and is in response to the firstmessage.

In a sixth aspect, a distributed system operates in a landscape ofcomputer systems providing message-based services. The system processesbusiness objects involving processing a form that may be filed by thetaxpayer or the taxpayer's representative. The system includes memoryand a graphical user interface remote from the memory. The memory storesa business object repository storing a plurality of business objects.Each business object is a logically centralized, semantically disjointedobject of a particular business object type. At least one of thebusiness objects represents a form that may be filed by the taxpayer orthe taxpayer's representative. The business object includes datalogically organized as a tax form root node, a usage data subordinatenode, and a property valuation subordinate node. The usage data nodecontains a billing period subordinate node. The graphical user interfacepresents data associated with an invoked instance of the tax formbusiness object. The user interface includes computer readableinstructions embodied on tangible media.

In a seventh aspect, a tangible computer readable medium includesprogram code for providing a message-based interface for performing atax object service. The service exposes at least one service as definedin a service registry. Upon execution, the program code executes in anenvironment of computer systems providing message-based services. Theprogram code receives, from a service consumer, a first message forprocessing a subject of a tax assessment, including attributes which area basis for a tax calculation. The program code invokes a tax objectbusiness object. The business object is a logically centralized,semantically disjointed object representing a subject of a taxassessment, including attributes which are a basis for a taxcalculation. The business object includes data logically organized as atax object root node, a business license assignment subordinate node, aproperty group subordinate node, a property valuation subordinate node,a location data subordinate node, and a tax obligation assignmentsubordinate node. The program code initiates transmission of a messageto a heterogeneous second application, executing in the environment ofcomputer systems providing message-based services. The message is basedon the data in the tax object business object. The message includes atax object enterprise resource planning by business partner querymessage entity, a message header package, a tax object selection by taxpayer party ID package, and a query processing conditions package.

In an eighth aspect, a tangible computer readable medium includesprogram code for providing a message-based interface for performing atax object service. The service exposes at least one service as definedin a service registry. Upon execution, the program code executes in anenvironment of computer systems providing message-based services. Theprogram code initiates transmission of a message to a heterogeneoussecond application, executing in the environment of computer systemsproviding message-based services. The message is based on data in a taxobject business object invoked by the second application. The businessobject is a logically centralized, semantically disjointed objectrepresenting a subject of a tax assessment, including attributes whichare a basis for a tax calculation. The business object includes datalogically organized as a tax object root node, a business licenseassignment subordinate node, a property group subordinate node, aproperty valuation subordinate node, a location data subordinate node,and a tax obligation assignment subordinate node. The message includes atax object enterprise resource planning by business partner querymessage entity, a message header package, a tax object selection by taxpayer party ID package, and a query processing conditions package. Theprogram code receives a second message from the second application. Thesecond message is associated with the invoked tax object business objectand is in response to the first message.

In a nineth aspect, a distributed system operates in a landscape ofcomputer systems providing message-based services. The system processesbusiness objects involving processing a subject of a tax assessment,including attributes which are a basis for a tax calculation. The systemincludes memory and a graphical user interface remote from the memory.The memory stores a business object repository storing a plurality ofbusiness objects. Each business object is a logically centralized,semantically disjointed object of a particular business object type. Atleast one of the business objects represents a subject of a taxassessment, including attributes which are a basis for a taxcalculation. The business object includes data logically organized as atax object root node, a business license assignment subordinate node, aproperty group subordinate node, a property valuation subordinate node,a location data subordinate node, and a tax obligation assignmentsubordinate node. The graphical user interface presents data associatedwith an invoked instance of the tax object business object. The userinterface includes computer readable instructions embodied on tangiblemedia.

In a tenth aspect, a tangible computer readable medium includes programcode for providing a message-based interface for performing a taxobligation service. The service exposes at least one service as definedin a service registry. Upon execution, the program code executes in anenvironment of computer systems providing message-based services. Theprogram code receives, from a service consumer, a first message forprocessing a legal requirement that may be fulfilled by a taxpayer,including obligations to file tax returns, pay taxes at defined duedates, and pay penalties for lack of fulfillment. The program codeinvokes a tax obligation business object. The business object is alogically centralized, semantically disjointed object representing alegal requirement that may be fulfilled by a taxpayer, includingobligations to file tax returns, pay taxes at defined due dates, and paypenalties for lack of fulfillment. The business object includes datalogically organized as a tax obligation root node, a filing obligationsubordinate node, a filing rule subordinate node, a filing exemptionsubordinate node, an invoicing terms subordinate node, and aregistration form subordinate node. The filing rule node contains adeviating period subordinate node and a standard period subordinatenode. The registration form node contains a property valuationsubordinate node The program code initiates transmission of a message toa heterogeneous second application, executing in the environment ofcomputer systems providing message-based services. The message is basedon the data in the tax obligation business object. The message includesa tax obligation enterprise resource planning message entity, a messageheader package, a tax obligation package, and a log package.

In an eleventh aspect, a tangible computer readable medium includesprogram code for providing a message-based interface for performing atax obligation service. The service exposes at least one service asdefined in a service registry. Upon execution, the program code executesin an environment of computer systems providing message-based services.The program code initiates transmission of a message to a heterogeneoussecond application, executing in the environment of computer systemsproviding message-based services. The message is based on data in a taxobligation business object invoked by the second application. Thebusiness object is a logically centralized, semantically disjointedobject representing a legal requirement that may be fulfilled by ataxpayer, including obligations to file tax returns, pay taxes atdefined due dates, and pay penalties for lack of fulfillment. Thebusiness object includes data logically organized as a tax obligationroot node, a filing obligation subordinate node, a filing rulesubordinate node, a filing exemption subordinate node, an invoicingterms subordinate node, and a registration form subordinate node. Thefiling rule node contains a deviating period subordinate node and astandard period subordinate node. The registration form node contains aproperty valuation subordinate node. The message includes a taxobligation enterprise resource planning message entity, a message headerpackage, a tax obligation package, and a log package. The program codereceives a second message from the second application. The secondmessage is associated with the invoked tax obligation business objectand is in response to the first message.

In a twelfth aspect, a distributed system operates in a landscape ofcomputer systems providing message-based services. The system processesbusiness objects involving processing a legal requirement that may befulfilled by a taxpayer, including obligations to file tax returns, paytaxes at defined due dates, and pay penalties for lack of fulfillment.The system includes memory and a graphical user interface remote fromthe memory. The memory stores a business object repository storing aplurality of business objects. Each business object is a logicallycentralized, semantically disjointed object of a particular businessobject type. At least one of the business objects represents a legalrequirement that may be fulfilled by a taxpayer, including obligationsto file tax returns, pay taxes at defined due dates, and pay penaltiesfor lack of fulfillment. The business object includes data logicallyorganized as a tax obligation root node, a filing obligation subordinatenode, a filing rule subordinate node, a filing exemption subordinatenode, an invoicing terms subordinate node, and a registration formsubordinate node. The filing rule node contains a deviating periodsubordinate node and a standard period subordinate node. Theregistration form node contains a property valuation subordinate node.The graphical user interface presents data associated with an invokedinstance of the tax obligation business object. The user interfaceincludes computer readable instructions embodied on tangible media.

In a thirteenth aspect, a tangible computer readable medium includesprogram code for providing a message-based interface for performing atax return service. The service exposes at least one service as definedin a service registry. Upon execution, the program code executes in anenvironment of computer systems providing message-based services. Theprogram code receives, from a service consumer, a first message forprocessing a person's, a company's or an organization's tax detailswhich taxpayers, or their legal representatives, may complete and sendto a tax authority, using forms prescribed by the tax authority. Theprogram code invokes a tax return business object. The business objectis a logically centralized, semantically disjointed object representinga person's, a company's or an organization's tax details whichtaxpayers, or their legal representatives, may complete and send to atax authority, using forms prescribed by the tax authority. The programcode includes data logically organized as a tax return root node, asystem status subordinate node, a user status subordinate node, a formsubordinate node, a tax payer subordinate node, a tax preparersubordinate node, and a joint filer subordinate node. The form nodecontains a property valuation subordinate node. The tax payer nodecontains an identification subordinate node. The tax preparer nodecontains an identification subordinate node. The joint filer nodecontains an identification subordinate node. The program code initiatestransmission of a message to a heterogeneous second application,executing in the environment of computer systems providing message-basedservices. The message is based on the data in the tax return businessobject. The message includes a tax return enterprise resource planningmessage entity, a message header package, a tax return package, and alog package.

In a fourteenth aspect, a tangible computer readable medium includesprogram code for providing a message-based interface for performing atax return service. The service exposes at least one service as definedin a service registry. Upon execution, the program code executes in anenvironment of computer systems providing message-based services. Theprogram code initiates transmission of a message to a heterogeneoussecond application, executing in the environment of computer systemsproviding message-based services. The message is based on data in a taxreturn business object invoked by the second application. The businessobject is a logically centralized, semantically disjointed objectrepresenting a person's, a company's or an organization's tax detailswhich taxpayers, or their legal representatives, may complete and sendto a tax authority, using forms prescribed by the tax authority. Thebusiness object includes data logically organized as a tax return rootnode, a system status subordinate node, a user status subordinate node,a form subordinate node, a tax payer subordinate node, a tax preparersubordinate node, and a joint filer subordinate node. The form nodecontains a property valuation subordinate node. The tax payer nodecontains an identification subordinate node. The tax preparer nodecontains an identification subordinate node. The joint filer nodecontains an identification subordinate node. The message includes a taxreturn enterprise resource planning message entity, a message headerpackage, a tax return package, and a log package. The program codereceives a second message from the second application. The secondmessage is associated with the invoked tax return business object and isin response to the first message.

In a fifteenth aspect, a distributed system operates in a landscape ofcomputer systems providing message-based services. The system processesbusiness objects involving processing a person's, a company's or anorganization's tax details which taxpayers, or their legalrepresentatives, may complete and send to a tax authority, using formsprescribed by the tax authority. The system includes memory and agraphical user interface remote from the memory. The memory stores abusiness object repository storing a plurality of business objects. Eachbusiness object is a logically centralized, semantically disjointedobject of a particular business object type. At least one of thebusiness objects represents a person's, a company's or an organization'stax details which taxpayers, or their legal representatives, maycomplete and send to a tax authority, using forms prescribed by the taxauthority. The business object includes data logically organized as atax return root node, a system status subordinate node, a user statussubordinate node, a form subordinate node, a tax payer subordinate node,a tax preparer subordinate node, and a joint filer subordinate node. Theform node contains a property valuation subordinate node. The tax payernode contains an identification subordinate node. The tax preparer nodecontains an identification subordinate node. The joint filer nodecontains an identification subordinate node. The graphical userinterface presents data associated with an invoked instance of the taxreturn business object. The user interface includes computer readableinstructions embodied on tangible media.

In some implementations, processing business objects includes creating,updating and/or retrieving information associated with the businessobjects.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a flow diagram of the overall steps performed by methodsand systems consistent with the subject matter described herein.

FIG. 2 depicts a business document flow for an invoice request inaccordance with methods and systems consistent with the subject matterdescribed herein.

FIGS. 3A-B illustrate example environments implementing thetransmission, receipt, and processing of data between heterogeneousapplications in accordance with certain embodiments included in thepresent disclosure.

FIG. 4 illustrates an example application implementing certaintechniques and components in accordance with one embodiment of thesystem of FIG. 1.

FIG. 5A depicts an example development environment in accordance withone embodiment of FIG. 1.

FIG. 5B depicts a simplified process for mapping a model representationto a runtime representation using the example development environment ofFIG. 5A or some other development environment.

FIG. 6 depicts message categories in accordance with methods and systemsconsistent with the subject matter described herein.

FIG. 7 depicts an example of a package in accordance with methods andsystems consistent with the subject matter described herein.

FIG. 8 depicts another example of a package in accordance with methodsand systems consistent with the subject matter described herein.

FIG. 9 depicts a third example of a package in accordance with methodsand systems consistent with the subject matter described herein.

FIG. 10 depicts a fourth example of a package in accordance with methodsand systems consistent with the subject matter described herein.

FIG. 11 depicts the representation of a package in the XML schema inaccordance with methods and systems consistent with the subject matterdescribed herein.

FIG. 12 depicts a graphical representation of cardinalities between twoentities in accordance with methods and systems consistent with thesubject matter described herein.

FIG. 13 depicts an example of a composition in accordance with methodsand systems consistent with the subject matter described herein.

FIG. 14 depicts an example of a hierarchical relationship in accordancewith methods and systems consistent with the subject matter describedherein.

FIG. 15 depicts an example of an aggregating relationship in accordancewith methods and systems consistent with the subject matter describedherein.

FIG. 16 depicts an example of an association in accordance with methodsand systems consistent with the subject matter described herein.

FIG. 17 depicts an example of a specialization in accordance withmethods and systems consistent with the subject matter described herein.

FIG. 18 depicts the categories of specializations in accordance withmethods and systems consistent with the subject matter described herein.

FIG. 19 depicts an example of a hierarchy in accordance with methods andsystems consistent with the subject matter described herein.

FIG. 20 depicts a graphical representation of a hierarchy in accordancewith methods and systems consistent with the subject matter describedherein.

FIGS. 21A-B depict a flow diagram of the steps performed to create abusiness object model in accordance with methods and systems consistentwith the subject matter described herein.

FIGS. 22A-F depict a flow diagram of the steps performed to generate aninterface from the business object model in accordance with methods andsystems consistent with the subject matter described herein.

FIG. 23 depicts an example illustrating the transmittal of a businessdocument in accordance with methods and systems consistent with thesubject matter described herein.

FIG. 24 depicts an interface proxy in accordance with methods andsystems consistent with the subject matter described herein.

FIG. 25 depicts an example illustrating the transmittal of a messageusing proxies in accordance with methods and systems consistent with thesubject matter described herein.

FIG. 26A depicts components of a message in accordance with methods andsystems consistent with the subject matter described herein.

FIG. 26B depicts IDs used in a message in accordance with methods andsystems consistent with the subject matter described herein.

FIGS. 27A-E depict a hierarchization process in accordance with methodsand systems consistent with the subject matter described herein.

FIG. 28 illustrates an example method for service enabling in accordancewith one embodiment of the present disclosure.

FIG. 29 is a graphical illustration of an example business object andassociated components as may be used in the enterprise serviceinfrastructure system of the present disclosure.

FIG. 30 illustrates an example method for managing a process agentframework in accordance with one embodiment of the present disclosure.

FIG. 31 illustrates an example method for status and action managementin accordance with one embodiment of the present disclosure.

FIG. 32 illustrates an exemplary TaxAssessmentNotice MessageChoreography.

FIGS. 33-1 through 33-2 illustrate an exemplaryTaxAssessmentNoticeERPMessage_Sync Element Structure.

FIG. 34 illustrates an exemplaryTaxAssessmentNoticeERPByBusinessPartnerQueryMessage_Sync ElementStructure.

FIGS. 35-1 through 35-2 illustrate an exemplaryTaxAssessmentNoticeERPByBusinessPartnerResponseMessage_Sync ElementStructure.

FIGS. 36-1 through 36-4 illustrate an exemplary TaxFormERPMessage_SyncElement Structure.

FIG. 37 illustrates an exemplary TaxFormERPByLevyTypeQueryMessage_SyncElement Structure.

FIGS. 38-1 through 38-4 illustrate an exemplaryTaxFormERPByLevyTypeResponseMessage_Sync Element Structure.

FIG. 39 illustrates an exemplary TaxFormERPByIDQueryMessage_Sync ElementStructure.

FIGS. 40-1 through 40-4 illustrate an exemplaryTaxFormERPByIDResponseMessage_Sync Element Structure.

FIG. 41 illustrates an exemplary TaxObject Message Choreography.

FIGS. 42-1 through 42-6 illustrate an exemplary TaxObjectERPMessage_SyncElement Structure.

FIGS. 43-1 through 43-2 illustrate an exemplaryTaxObjectERPByBusinessPartnerQueryMessage_sync Element Structure.

FIGS. 44-1 through 44-4 illustrate an exemplaryTaxObjectERPByBusinessPartnerResponseMessage_sync Element Structure.

FIG. 45 illustrates an exemplary TaxObjectERPByIdQuery_sync ElementStructure.

FIGS. 46-1 through 46-3 illustrate an exemplaryTaxObjectERPByIdResponse_sync Element Structure.

FIGS. 47-1 through 47-2 illustrate an exemplaryTaxObjectERPCreateRequest_sync Element Structure.

FIGS. 48-1 through 48-3 illustrate an exemplaryTaxObjectERPCreateConfirmation_sync Element Structure.

FIGS. 49-1 through 49-3 illustrate an exemplaryTaxObjectERPUpdateRequest_sync Element Structure.

FIGS. 50-1 through 50-3 illustrate an exemplaryTaxObjectERPUpdateConfirmation_sync Element Structure.

FIGS. 51-1 through 51-2 illustrate an exemplaryTaxObjectERPCheckQuery_sync Element Structure.

FIGS. 52-1 through 52-3 illustrate an exemplaryTaxObjectERPCheckResponse_sync Element Structure.

FIG. 53 illustrates an exemplary TaxObligation Message Choreography.

FIGS. 54-1 through 54-15 illustrate an exemplaryTaxObligationERPMessage_Sync Element Structure.

FIGS. 55-1 through 55-7 illustrate an exemplaryTaxObligationERPChangeRequestMessage_Sync Element Structure.

FIGS. 56-1 through 56-9 illustrate an exemplaryTaxObligationERPChangeConfirmationMessage_Sync Element Structure.

FIGS. 57-1 through 57-3 illustrate an exemplaryTaxObligationERPFilingObligationChangeRequestMessage_Sync ElementStructure.

FIGS. 58-1 through 58-5 illustrate an exemplaryTaxObligationERPFilingObligationChangeConfirmationMessage_Sync ElementStructure.

FIGS. 59-1 through 59-7 illustrate an exemplaryTaxObligationERPCheckQueryMessage_Sync Element Structure.

FIGS. 60-1 through 60-9 illustrate an exemplaryTaxObligationERPCheckResponseMessage_Sync Element Structure.

FIGS. 61-1 through 61-3 illustrate an exemplaryTaxObligationERPFilingObligationCheckQueryMessage_Sync ElementStructure.

FIGS. 62-1 through 62-5 illustrate an exemplaryTaxObligationERPFilingObligationCheckResponseMessage_Sync ElementStructure.

FIGS. 63-1 through 63-6 illustrate an exemplaryTaxObligationERPCreateRequestMessage_Sync Element Structure.

FIGS. 64-1 through 64-9 illustrate an exemplaryTaxObligationERPCreateConfirmationMessage_Sync Element Structure.

FIGS. 65-1 through 65-2 illustrate an exemplaryTaxObligationERPByBusinessPartnerQueryMessage_Sync Element Structure.

FIGS. 66-1 through 66-8 illustrate an exemplaryTaxObligationERPByBusinessPartnerResponseMessage_Sync Element Structure.

FIGS. 67-1 through 67-2 illustrate an exemplaryTaxObligationERPLevyTypeByBusinessPartnerQueryMessage_Sync ElementStructure.

FIGS. 68-1 through 68-2 illustrate an exemplaryTaxObligationERPLevyTypeByBusinessPartnerResponseMessage_Sync ElementStructure.

FIG. 69 illustrates an exemplaryTaxObligationERPRegistrationFormByIdQueryMessage_Sync Element Structure.

FIGS. 70-1 through 70-3 illustrate an exemplaryTaxObligationERPRegistrationFormByIdResponseMessage_Sync ElementStructure.

FIG. 71 illustrates an exemplaryTaxObligationERPFilingObligationByIdQueryMessage Element Structure.

FIGS. 72-1 through 72-5 illustrate an exemplaryTaxObligationERPFilingObligationByIdResponseMessage_Sync ElementStructure.

FIG. 73 illustrates an exemplary TaxObligationERPByIdQueryMessage_SyncElement Structure.

FIGS. 74-1 through 74-12 illustrate an exemplaryTaxObligationERPByIdResponseMessage_Sync Element Structure.

FIG. 75 illustrates an exemplary TaxReturn Message Choreography.

FIGS. 76-1 through 76-12 illustrate an exemplaryTaxReturnERPMessage_Sync Element Structure.

FIGS. 77-1 through 77-9 illustrate an exemplaryTaxReturnERPByBusinessPartnerQueryMessage_Sync Element Structure.

FIGS. 78-1 through 78-3 illustrate an exemplaryTaxReturnERPByBusinessPartnerResponseMessage_Sync Element Structure.

FIG. 79 illustrates an exemplary TaxReturnERPByIdQueryMessage_SyncElement Structure.

FIGS. 80-1 through 80-10 illustrate an exemplaryTaxReturnERPByIdResponseMessage_Sync Element Structure.

FIGS. 81-1 through 81-4 illustrate an exemplaryTaxReturnERPCreateRequestMessage_Sync Element Structure.

FIGS. 82-1 through 82-10 illustrate an exemplaryTaxReturnERPCreateConfirmationMessage_Sync Element Structure.

FIGS. 83-1 through 83-3 illustrate an exemplaryTaxReturnERPValidateRequestMessage_Sync Element Structure.

FIGS. 84-1 through 84-10 illustrate an exemplaryTaxReturnERPValidateConfirmationMessage_Sync Element Structure.

FIGS. 85-1 through 85-4 illustrate an exemplaryTaxReturnERPChangeRequestMessage_Sync Element Structure.

FIGS. 86-1 through 86-10 illustrate an exemplaryTaxReturnERPChangeConfirmationMessage_Sync Element Structure.

DETAILED DESCRIPTION

A. Overview

Methods and systems consistent with the subject matter described hereinfacilitate e-commerce by providing consistent interfaces that aresuitable for use across industries, across businesses, and acrossdifferent departments within a business during a business transaction.To generate consistent interfaces, methods and systems consistent withthe subject matter described herein utilize a business object model,which reflects the data that will be used during a given businesstransaction. An example of a business transaction is the exchange ofpurchase orders and order confirmations between a buyer and a seller.The business object model is generated in a hierarchical manner toensure that the same type of data is represented the same way throughoutthe business object model. This ensures the consistency of theinformation in the business object model. Consistency is also reflectedin the semantic meaning of the various structural elements. That is,each structural element has a consistent business meaning. For example,the location entity, regardless of in which package it is located,refers to a location.

From this business object model, various interfaces are derived toaccomplish the functionality of the business transaction. Interfacesprovide an entry point for components to access the functionality of anapplication. For example, the interface for a Purchase Order Requestprovides an entry point for components to access the functionality of aPurchase Order, in particular, to transmit and/or receive a PurchaseOrder Request. One skilled in the art will recognize that each of theseinterfaces may be provided, sold, distributed, utilized, or marketed asa separate product or as a major component of a separate product.Alternatively, a group of related interfaces may be provided, sold,distributed, utilized, or marketed as a product or as a major componentof a separate product. Because the interfaces are generated from thebusiness object model, the information in the interfaces is consistent,and the interfaces are consistent among the business entities. Suchconsistency facilitates heterogeneous business entities in cooperatingto accomplish the business transaction.

Generally, the business object is a representation of a type of auniquely identifiable business entity (an object instance) described bya structural model. In the architecture, processes may typically operateon business objects. Business objects represent a specific view on somewell-defined business content. In other words, business objectsrepresent content, which a typical business user would expect andunderstand with little explanation. Business objects are furthercategorized as business process objects and master data objects. Amaster data object is an object that encapsulates master data (i.e.,data that is valid for a period of time). A business process object,which is the kind of business object generally found in a processcomponent, is an object that encapsulates transactional data (i.e., datathat is valid for a point in time). The term business object will beused generically to refer to a business process object and a master dataobject, unless the context requires otherwise. Properly implemented,business objects are implemented free of redundancies.

The architectural elements also include the process component. Theprocess component is a software package that realizes a business processand generally exposes its functionality as services. The functionalitycontains business transactions. In general, the process componentcontains one or more semantically related business objects. Often, aparticular business object belongs to no more than one processcomponent. Interactions between process component pairs involving theirrespective business objects, process agents, operations, interfaces, andmessages are described as process component interactions, whichgenerally determine the interactions of a pair of process componentsacross a deployment unit boundary. Interactions between processcomponents within a deployment unit are typically not constrained by thearchitectural design and can be implemented in any convenient fashion.Process components may be modular and context-independent. In otherwords, process components may not be specific to any particularapplication and as such, may be reusable. In some implementations, theprocess component is the smallest (most granular) element of reuse inthe architecture. An external process component is generally used torepresent the external system in describing interactions with theexternal system; however, this should be understood to require no moreof the external system than that able to produce and receive messages asrequired by the process component that interacts with the externalsystem. For example, process components may include multiple operationsthat may provide interaction with the external system. Each operationgenerally belongs to one type of process component in the architecture.Operations can be synchronous or asynchronous, corresponding tosynchronous or asynchronous process agents, which will be describedbelow. The operation is often the smallest, separately-callablefunction, described by a set of data types used as input, output, andfault parameters serving as a signature.

The architectural elements may also include the service interface,referred to simply as the interface. The interface is a named group ofoperations. The interface often belongs to one process component andprocess component might contain multiple interfaces. In oneimplementation, the service interface contains only inbound or outboundoperations, but not a mixture of both. One interface can contain bothsynchronous and asynchronous operations. Normally, operations of thesame type (either inbound or outbound) which belong to the same messagechoreography will belong to the same interface. Thus, generally, alloutbound operations to the same other process component are in oneinterface.

The architectural elements also include the message. Operations transmitand receive messages. Any convenient messaging infrastructure can beused. A message is information conveyed from one process componentinstance to another, with the expectation that activity will ensue.Operation can use multiple message types for inbound, outbound, or errormessages. When two process components are in different deployment units,invocation of an operation of one process component by the other processcomponent is accomplished by the operation on the other processcomponent sending a message to the first process component.

The architectural elements may also include the process agent. Processagents do business processing that involves the sending or receiving ofmessages. Each operation normally has at least one associated processagent. Each process agent can be associated with one or more operations.Process agents can be either inbound or outbound and either synchronousor asynchronous. Asynchronous outbound process agents are called after abusiness object changes such as after a “create”, “update”, or “delete”of a business object instance. Synchronous outbound process agents aregenerally triggered directly by business object. An outbound processagent will generally perform some processing of the data of the businessobject instance whose change triggered the event. The outbound agenttriggers subsequent business process steps by sending messages usingwell-defined outbound services to another process component, whichgenerally will be in another deployment unit, or to an external system.The outbound process agent is linked to the one business object thattriggers the agent, but it is sent not to another business object butrather to another process component. Thus, the outbound process agentcan be implemented without knowledge of the exact business object designof the recipient process component. Alternatively, the process agent maybe inbound. For example, inbound process agents may be used for theinbound part of a message-based communication. Inbound process agentsare called after a message has been received. The inbound process agentstarts the execution of the business process step requested in a messageby creating or updating one or multiple business object instances.Inbound process agent is not generally the agent of business object butof its process component. Inbound process agent can act on multiplebusiness objects in a process component. Regardless of whether theprocess agent is inbound or outbound, an agent may be synchronous ifused when a process component requires a more or less immediate responsefrom another process component, and is waiting for that response tocontinue its work.

The architectural elements also include the deployment unit. Eachdeployment unit may include one or more process components that aregenerally deployed together on a single computer system platform.Conversely, separate deployment units can be deployed on separatephysical computing systems. The process components of one deploymentunit can interact with those of another deployment unit using messagespassed through one or more data communication networks or other suitablecommunication channels. Thus, a deployment unit deployed on a platformbelonging to one business can interact with a deployment unit softwareentity deployed on a separate platform belonging to a different andunrelated business, allowing for business-to-business communication.More than one instance of a given deployment unit can execute at thesame time, on the same computing system or on separate physicalcomputing systems. This arrangement allows the functionality offered bythe deployment unit to be scaled to meet demand by creating as manyinstances as needed.

Since interaction between deployment units is through process componentoperations, one deployment unit can be replaced by other anotherdeployment unit as long as the new deployment unit supports theoperations depended upon by other deployment units as appropriate. Thus,while deployment units can depend on the external interfaces of processcomponents in other deployment units, deployment units are not dependenton process component interaction within other deployment units.Similarly, process components that interact with other processcomponents or external systems only through messages, e.g., as sent andreceived by operations, can also be replaced as long as the replacementgenerally supports the operations of the original.

Services (or interfaces) may be provided in a flexible architecture tosupport varying criteria between services and systems. The flexiblearchitecture may generally be provided by a service delivery businessobject. The system may be able to schedule a service asynchronously asnecessary, or on a regular basis. Services may be planned according to aschedule manually or automatically. For example, a follow-up service maybe scheduled automatically upon completing an initial service. Inaddition, flexible execution periods may be possible (e.g. hourly,daily, every three months, etc.). Each customer may plan the services ondemand or reschedule service execution upon request.

FIG. 1 depicts a flow diagram 100 showing an example technique, perhapsimplemented by systems similar to those disclosed herein. Initially, togenerate the business object model, design engineers study the detailsof a business process, and model the business process using a “businessscenario” (step 102). The business scenario identifies the stepsperformed by the different business entities during a business process.Thus, the business scenario is a complete representation of a clearlydefined business process.

After creating the business scenario, the developers add details to eachstep of the business scenario (step 104). In particular, for each stepof the business scenario, the developers identify the complete processsteps performed by each business entity. A discrete portion of thebusiness scenario reflects a “business transaction,” and each businessentity is referred to as a “component” of the business transaction. Thedevelopers also identify the messages that are transmitted between thecomponents. A “process interaction model” represents the completeprocess steps between two components.

After creating the process interaction model, the developers create a“message choreography” (step 106), which depicts the messagestransmitted between the two components in the process interaction model.The developers then represent the transmission of the messages betweenthe components during a business process in a “business document flow”(step 108). Thus, the business document flow illustrates the flow ofinformation between the business entities during a business process.

FIG. 2 depicts an example business document flow 200 for the process ofpurchasing a product or service. The business entities involved with theillustrative purchase process include Accounting 202, Payment 204,Invoicing 206, Supply Chain Execution (“SCE”) 208, Supply Chain Planning(“SCP”) 210, Fulfillment Coordination (“FC”) 212, Supply RelationshipManagement (“SRM”) 214, Supplier 216, and Bank 218. The businessdocument flow 200 is divided into four different transactions:Preparation of Ordering (“Contract”) 220, Ordering 222, Goods Receiving(“Delivery”) 224, and Billing/Payment 226. In the business documentflow, arrows 228 represent the transmittal of documents. Each documentreflects a message transmitted between entities. One of ordinary skillin the art will appreciate that the messages transferred may beconsidered to be a communications protocol. The process flow follows thefocus of control, which is depicted as a solid vertical line (e.g., 229)when the step is required, and a dotted vertical line (e.g., 230) whenthe step is optional.

During the Contract transaction 220, the SRM 214 sends a Source ofSupply Notification 232 to the SCP 210. This step is optional, asillustrated by the optional control line 230 coupling this step to theremainder of the business document flow 200. During the Orderingtransaction 222, the SCP 210 sends a Purchase Requirement Request 234 tothe FC 212, which forwards a Purchase Requirement Request 236 to the SRM214. The SRM 214 then sends a Purchase Requirement Confirmation 238 tothe FC 212, and the FC 212 sends a Purchase Requirement Confirmation 240to the SCP 210. The SRM 214 also sends a Purchase Order Request 242 tothe Supplier 216, and sends Purchase Order Information 244 to the FC212. The FC 212 then sends a Purchase Order Planning Notification 246 tothe SCP 210. The Supplier 216, after receiving the Purchase OrderRequest 242, sends a Purchase Order Confirmation 248 to the SRM 214,which sends a Purchase Order Information confirmation message 254 to theFC 212, which sends a message 256 confirming the Purchase Order PlanningNotification to the SCP 210. The SRM 214 then sends an Invoice DueNotification 258 to Invoicing 206.

During the Delivery transaction 224, the FC 212 sends a DeliveryExecution Request 260 to the SCE 208. The Supplier 216 could optionally(illustrated at control line 250) send a Dispatched DeliveryNotification 252 to the SCE 208. The SCE 208 then sends a message 262 tothe FC 212 notifying the FC 212 that the request for the DeliveryInformation was created. The FC 212 then sends a message 264 notifyingthe SRM 214 that the request for the Delivery Information was created.The FC 212 also sends a message 266 notifying the SCP 210 that therequest for the Delivery Information was created. The SCE 208 sends amessage 268 to the FC 212 when the goods have been set aside fordelivery. The FC 212 sends a message 270 to the SRM 214 when the goodshave been set aside for delivery. The FC 212 also sends a message 272 tothe SCP 210 when the goods have been set aside for delivery.

The SCE 208 sends a message 274 to the FC 212 when the goods have beendelivered. The FC 212 then sends a message 276 to the SRM 214 indicatingthat the goods have been delivered, and sends a message 278 to the SCP210 indicating that the goods have been delivered. The SCE 208 thensends an Inventory Change Accounting Notification 280 to Accounting 202,and an Inventory Change Notification 282 to the SCP 210. The FC 212sends an Invoice Due Notification 284 to Invoicing 206, and SCE 208sends a Received Delivery Notification 286 to the Supplier 216.

During the Billing/Payment transaction 226, the Supplier 216 sends anInvoice Request 287 to Invoicing 206. Invoicing 206 then sends a PaymentDue Notification 288 to Payment 204, a Tax Due Notification 289 toPayment 204, an Invoice Confirmation 290 to the Supplier 216, and anInvoice Accounting Notification 291 to Accounting 202. Payment 204 sendsa Payment Request 292 to the Bank 218, and a Payment RequestedAccounting Notification 293 to Accounting 202. Bank 218 sends a BankStatement Information 296 to Payment 204. Payment 204 then sends aPayment Done Information 294 to Invoicing 206 and a Payment DoneAccounting Notification 295 to Accounting 202.

Within a business document flow, business documents having the same orsimilar structures are marked. For example, in the business documentflow 200 depicted in FIG. 2, Purchase Requirement Requests 234, 236 andPurchase Requirement Confirmations 238, 240 have the same structures.Thus, each of these business documents is marked with an “O6.”Similarly, Purchase Order Request 242 and Purchase Order Confirmation248 have the same structures. Thus, both documents are marked with an“O1.” Each business document or message is based on a message type.

From the business document flow, the developers identify the businessdocuments having identical or similar structures, and use these businessdocuments to create the business object model (step 110). The businessobject model includes the objects contained within the businessdocuments. These objects are reflected as packages containing relatedinformation, and are arranged in a hierarchical structure within thebusiness object model, as discussed below.

Methods and systems consistent with the subject matter described hereinthen generate interfaces from the business object model (step 112). Theheterogeneous programs use instantiations of these interfaces (called“business document objects” below) to create messages (step 114), whichare sent to complete the business transaction (step 116). Businessentities use these messages to exchange information with other businessentities during an end-to-end business transaction. Since the businessobject model is shared by heterogeneous programs, the interfaces areconsistent among these programs. The heterogeneous programs use theseconsistent interfaces to communicate in a consistent manner, thusfacilitating the business transactions.

Standardized Business-to-Business (“B2B”) messages are compliant with atleast one of the e-business standards (i.e., they include thebusiness-relevant fields of the standard). The e-business standardsinclude, for example, RosettaNet for the high-tech industry, ChemicalIndustry Data Exchange (“CIDX”), Petroleum Industry Data Exchange(“PIDX”) for the oil industry, UCCnet for trade, PapiNet for the paperindustry, Odette for the automotive industry, HR-XML for humanresources, and XML Common Business Library (“xCBL”). Thus, B2B messagesenable simple integration of components in heterogeneous systemlandscapes. Application-to-Application (“A2A”) messages often exceed thestandards and thus may provide the benefit of the full functionality ofapplication components. Although various steps of FIG. 1 were describedas being performed manually, one skilled in the art will appreciate thatsuch steps could be computer-assisted or performed entirely by acomputer, including being performed by either hardware, software, or anyother combination thereof.

B. Implementation Details

As discussed above, methods and systems consistent with the subjectmatter described herein create consistent interfaces by generating theinterfaces from a business object model. Details regarding the creationof the business object model, the generation of an interface from thebusiness object model, and the use of an interface generated from thebusiness object model are provided below.

Turning to the illustrated embodiment in FIG. 3A, environment 300includes or is communicably coupled (such as via a one-, bi- ormulti-directional link or network) with server 302, one or more clients304, one or more or vendors 306, one or more customers 308, at leastsome of which communicate across network 312. But, of course, thisillustration is for example purposes only, and any distributed system orenvironment implementing one or more of the techniques described hereinmay be within the scope of this disclosure. Server 302 comprises anelectronic computing device operable to receive, transmit, process andstore data associated with environment 300. Generally, FIG. 3A providesmerely one example of computers that may be used with the disclosure.Each computer is generally intended to encompass any suitable processingdevice. For example, although FIG. 3A illustrates one server 302 thatmay be used with the disclosure, environment 300 can be implementedusing computers other than servers, as well as a server pool. Indeed,server 302 may be any computer or processing device such as, forexample, a blade server, general-purpose personal computer (PC),Macintosh, workstation, Unix-based computer, or any other suitabledevice. In other words, the present disclosure contemplates computersother than general purpose computers as well as computers withoutconventional operating systems. Server 302 may be adapted to execute anyoperating system including Linux, UNIX, Windows Server, or any othersuitable operating system. According to one embodiment, server 302 mayalso include or be communicably coupled with a web server and/or a mailserver.

As illustrated (but not required), the server 302 is communicablycoupled with a relatively remote repository 335 over a portion of thenetwork 312. The repository 335 is any electronic storage facility, dataprocessing center, or archive that may supplement or replace localmemory (such as 327). The repository 335 may be a central databasecommunicably coupled with the one or more servers 302 and the clients304 via a virtual private network (VPN), SSH (Secure Shell) tunnel, orother secure network connection. The repository 335 may be physically orlogically located at any appropriate location including in one of theexample enterprises or off-shore, so long as it remains operable tostore information associated with the environment 300 and communicatesuch data to the server 302 or at least a subset of plurality of theclients 304.

Illustrated server 302 includes local memory 327. Memory 327 may includeany memory or database module and may take the form of volatile ornon-volatile memory including, without limitation, magnetic media,optical media, random access memory (RAM), read-only memory (ROM),removable media, or any other suitable local or remote memory component.Illustrated memory 327 includes an exchange infrastructure (“XI”) 314,which is an infrastructure that supports the technical interaction ofbusiness processes across heterogeneous system environments. XI 314centralizes the communication between components within a businessentity and between different business entities. When appropriate, XI 314carries out the mapping between the messages. XI 314 integratesdifferent versions of systems implemented on different platforms (e.g.,Java and ABAP). XI 314 is based on an open architecture, and makes useof open standards, such as eXtensible Markup Language (XML)™ and Javaenvironments. XI 314 offers services that are useful in a heterogeneousand complex system landscape. In particular, XI 314 offers a runtimeinfrastructure for message exchange, configuration options for managingbusiness processes and message flow, and options for transformingmessage contents between sender and receiver systems.

XI 314 stores data types 316, a business object model 318, andinterfaces 320. The details regarding the business object model aredescribed below. Data types 316 are the building blocks for the businessobject model 318. The business object model 318 is used to deriveconsistent interfaces 320. XI 314 allows for the exchange of informationfrom a first company having one computer system to a second companyhaving a second computer system over network 312 by using thestandardized interfaces 320.

While not illustrated, memory 327 may also include business objects andany other appropriate data such as services, interfaces, VPNapplications or services, firewall policies, a security or access log,print or other reporting files, HTML files or templates, data classes orobject interfaces, child software applications or sub-systems, andothers. This stored data may be stored in one or more logical orphysical repositories. In some embodiments, the stored data (or pointersthereto) may be stored in one or more tables in a relational databasedescribed in terms of SQL statements or scripts. In the same or otherembodiments, the stored data may also be formatted, stored, or definedas various data structures in text files, XML documents, Virtual StorageAccess Method (VSAM) files, flat files, Btrieve files,comma-separated-value (CSV) files, internal variables, or one or morelibraries. For example, a particular data service record may merely be apointer to a particular piece of third party software stored remotely.In another example, a particular data service may be an internallystored software object usable by authenticated customers or internaldevelopment. In short, the stored data may comprise one table or file ora plurality of tables or files stored on one computer or across aplurality of computers in any appropriate format. Indeed, some or all ofthe stored data may be local or remote without departing from the scopeof this disclosure and store any type of appropriate data.

Server 302 also includes processor 325. Processor 325 executesinstructions and manipulates data to perform the operations of server302 such as, for example, a central processing unit (CPU), a blade, anapplication specific integrated circuit (ASIC), or a field-programmablegate array (FPGA). Although FIG. 3A illustrates a single processor 325in server 302, multiple processors 325 may be used according toparticular needs and reference to processor 325 is meant to includemultiple processors 325 where applicable. In the illustrated embodiment,processor 325 executes at least business application 330.

At a high level, business application 330 is any application, program,module, process, or other software that utilizes or facilitates theexchange of information via messages (or services) or the use ofbusiness objects. For example, application 330 may implement, utilize orotherwise leverage an enterprise service-oriented architecture(enterprise SOA), which may be considered a blueprint for an adaptable,flexible, and open IT architecture for developing services-based,enterprise-scale business solutions. This example enterprise service maybe a series of web services combined with business logic that can beaccessed and used repeatedly to support a particular business process.Aggregating web services into business-level enterprise services helpsprovide a more meaningful foundation for the task of automatingenterprise-scale business scenarios Put simply, enterprise services helpprovide a holistic combination of actions that are semantically linkedto complete the specific task, no matter how many cross-applications areinvolved. In certain cases, environment 300 may implement a compositeapplication 330, as described below in FIG. 4. Regardless of theparticular implementation, “software” may include software, firmware,wired or programmed hardware, or any combination thereof as appropriate.Indeed, application 330 may be written or described in any appropriatecomputer language including C, C++, Java, Visual Basic, assembler, Perl,any suitable version of 4GL, as well as others. For example, returningto the above mentioned composite application, the composite applicationportions may be implemented as Enterprise Java Beans (EJBs) or thedesign-time components may have the ability to generate run-timeimplementations into different platforms, such as J2EE (Java 2 Platform,Enterprise Edition), ABAP (Advanced Business Application Programming)objects, or Microsoft's .NET. It will be understood that whileapplication 330 is illustrated in FIG. 4 as including varioussub-modules, application 330 may include numerous other sub-modules ormay instead be a single multi-tasked module that implements the variousfeatures and functionality through various objects, methods, or otherprocesses. Further, while illustrated as internal to server 302, one ormore processes associated with application 330 may be stored,referenced, or executed remotely. For example, a portion of application330 may be a web service that is remotely called, while another portionof application 330 may be an interface object bundled for processing atremote client 304. Moreover, application 330 may be a child orsub-module of another software module or enterprise application (notillustrated) without departing from the scope of this disclosure.Indeed, application 330 may be a hosted solution that allows multiplerelated or third parties in different portions of the process to performthe respective processing.

More specifically, as illustrated in FIG. 4, application 330 may be acomposite application, or an application built on other applications,that includes an object access layer (OAL) and a service layer. In thisexample, application 330 may execute or provide a number of applicationservices, such as customer relationship management (CRM) systems, humanresources management (HRM) systems, financial management (FM) systems,project management (PM) systems, knowledge management (KM) systems, andelectronic file and mail systems. Such an object access layer isoperable to exchange data with a plurality of enterprise base systemsand to present the data to a composite application through a uniforminterface. The example service layer is operable to provide services tothe composite application. These layers may help the compositeapplication to orchestrate a business process in synchronization withother existing processes (e.g., native processes of enterprise basesystems) and leverage existing investments in the IT platform. Further,composite application 330 may run on a heterogeneous IT platform. Indoing so, composite application may be cross-functional in that it maydrive business processes across different applications, technologies,and organizations. Accordingly, composite application 330 may driveend-to-end business processes across heterogeneous systems orsub-systems. Application 330 may also include or be coupled with apersistence layer and one or more application system connectors. Suchapplication system connectors enable data exchange and integration withenterprise sub-systems and may include an Enterprise Connector (EC)interface, an Internet Communication Manager/Internet CommunicationFramework (ICM/ICF) interface, an Encapsulated PostScript (EPS)interface, and/or other interfaces that provide Remote Function Call(RFC) capability. It will be understood that while this exampledescribes a composite application 330, it may instead be a standalone or(relatively) simple software program. Regardless, application 330 mayalso perform processing automatically, which may indicate that theappropriate processing is substantially performed by at least onecomponent of environment 300. It should be understood that automaticallyfurther contemplates any suitable administrator or other userinteraction with application 330 or other components of environment 300without departing from the scope of this disclosure.

Returning to FIG. 3A, illustrated server 302 may also include interface317 for communicating with other computer systems, such as clients 304,over network 312 in a client-server or other distributed environment. Incertain embodiments, server 302 receives data from internal or externalsenders through interface 317 for storage in memory 327, for storage inDB 335, and/or processing by processor 325. Generally, interface 317comprises logic encoded in software and/or hardware in a suitablecombination and operable to communicate with network 312. Morespecifically, interface 317 may comprise software supporting one or morecommunications protocols associated with communications network 312 orhardware operable to communicate physical signals.

Network 312 facilitates wireless or wireline communication betweencomputer server 302 and any other local or remote computer, such asclients 304. Network 312 may be all or a portion of an enterprise orsecured network. In another example, network 312 may be a VPN merelybetween server 302 and client 304 across wireline or wireless link. Suchan example wireless link may be via 802.11a, 802.11b, 802.11g, 802.20,WiMax, and many others. While illustrated as a single or continuousnetwork, network 312 may be logically divided into various sub-nets orvirtual networks without departing from the scope of this disclosure, solong as at least portion of network 312 may facilitate communicationsbetween server 302 and at least one client 304. For example, server 302may be communicably coupled to one or more “local” repositories throughone sub-net while communicably coupled to a particular client 304 or“remote” repositories through another. In other words, network 312encompasses any internal or external network, networks, sub-network, orcombination thereof operable to facilitate communications betweenvarious computing components in environment 300. Network 312 maycommunicate, for example, Internet Protocol (IP) packets, Frame Relayframes, Asynchronous Transfer Mode (ATM) cells, voice, video, data, andother suitable information between network addresses. Network 312 mayinclude one or more local area networks (LANs), radio access networks(RANs), metropolitan area networks (MANs), wide area networks (WANs),all or a portion of the global computer network known as the Internet,and/or any other communication system or systems at one or morelocations. In certain embodiments, network 312 may be a secure networkassociated with the enterprise and certain local or remote vendors 306and customers 308. As used in this disclosure, customer 308 is anyperson, department, organization, small business, enterprise, or anyother entity that may use or request others to use environment 300. Asdescribed above, vendors 306 also may be local or remote to customer308. Indeed, a particular vendor 306 may provide some content tobusiness application 330, while receiving or purchasing other content(at the same or different times) as customer 308. As illustrated,customer 308 and vendor 06 each typically perform some processing (suchas uploading or purchasing content) using a computer, such as client304.

Client 304 is any computing device operable to connect or communicatewith server 302 or network 312 using any communication link. Forexample, client 304 is intended to encompass a personal computer, touchscreen terminal, workstation, network computer, kiosk, wireless dataport, smart phone, personal data assistant (PDA), one or more processorswithin these or other devices, or any other suitable processing deviceused by or for the benefit of business 308, vendor 306, or some otheruser or entity. At a high level, each client 304 includes or executes atleast GUI 336 and comprises an electronic computing device operable toreceive, transmit, process and store any appropriate data associatedwith environment 300. It will be understood that there may be any numberof clients 304 communicably coupled to server 302. Further, “client304,” “business,” “business analyst,” “end user,” and “user” may be usedinterchangeably as appropriate without departing from the scope of thisdisclosure. Moreover, for ease of illustration, each client 304 isdescribed in terms of being used by one user. But this disclosurecontemplates that many users may use one computer or that one user mayuse multiple computers. For example, client 304 may be a PDA operable towirelessly connect with external or unsecured network. In anotherexample, client 304 may comprise a laptop that includes an input device,such as a keypad, touch screen, mouse, or other device that can acceptinformation, and an output device that conveys information associatedwith the operation of server 302 or clients 304, including digital data,visual information, or GUI 336. Both the input device and output devicemay include fixed or removable storage media such as a magnetic computerdisk, CD-ROM, or other suitable media to both receive input from andprovide output to users of clients 304 through the display, namely theclient portion of GUI or application interface 336.

GUI 336 comprises a graphical user interface operable to allow the userof client 304 to interface with at least a portion of environment 300for any suitable purpose, such as viewing application or othertransaction data. Generally, GUI 336 provides the particular user withan efficient and user-friendly presentation of data provided by orcommunicated within environment 300. For example, GUI 336 may presentthe user with the components and information that is relevant to theirtask, increase reuse of such components, and facilitate a sizabledeveloper community around those components. GUI 336 may comprise aplurality of customizable frames or views having interactive fields,pull-down lists, and buttons operated by the user. For example, GUI 336is operable to display data involving business objects and interfaces ina user-friendly form based on the user context and the displayed data.In another example, GUI 336 is operable to display different levels andtypes of information involving business objects and interfaces based onthe identified or supplied user role. GUI 336 may also present aplurality of portals or dashboards. For example, GUI 336 may display aportal that allows users to view, create, and manage historical andreal-time reports including role-based reporting and such. Of course,such reports may be in any appropriate output format including PDF,HTML, and printable text. Real-time dashboards often provide table andgraph information on the current state of the data, which may besupplemented by business objects and interfaces. It should be understoodthat the term graphical user interface may be used in the singular or inthe plural to describe one or more graphical user interfaces and each ofthe displays of a particular graphical user interface. Indeed, referenceto GUI 336 may indicate a reference to the front-end or a component ofbusiness application 330, as well as the particular interface accessiblevia client 304, as appropriate, without departing from the scope of thisdisclosure. Therefore, GUI 336 contemplates any graphical userinterface, such as a generic web browser or touchscreen, that processesinformation in environment 300 and efficiently presents the results tothe user. Server 302 can accept data from client 304 via the web browser(e.g., Microsoft Internet Explorer or Netscape Navigator) and return theappropriate HTML or XML responses to the browser using network 312.

More generally in environment 300 as depicted in FIG. 3B, a FoundationLayer 375 can be deployed on multiple separate and distinct hardwareplatforms, e.g., System A 350 and System B 360, to support applicationsoftware deployed as two or more deployment units distributed on theplatforms, including deployment unit 352 deployed on System A anddeployment unit 362 deployed on System B. In this example, thefoundation layer can be used to support application software deployed inan application layer. In particular, the foundation layer can be used inconnection with application software implemented in accordance with asoftware architecture that provides a suite of enterprise serviceoperations having various application functionality. In someimplementations, the application software is implemented to be deployedon an application platform that includes a foundation layer thatcontains all fundamental entities that can used from multiple deploymentunits. These entities can be process components, business objects, andreuse service components. A reuse service component is a piece ofsoftware that is reused in different transactions. A reuse servicecomponent is used by its defined interfaces, which can be, e.g., localAPIs or service interfaces. As explained above, process components inseparate deployment units interact through service operations, asillustrated by messages passing between service operations 356 and 366,which are implemented in process components 354 and 364, respectively,which are included in deployment units 352 and 362, respectively. Asalso explained above, some form of direct communication is generally theform of interaction used between a business object, e.g., businessobject 358 and 368, of an application deployment unit and a businessobject, such as master data object 370, of the Foundation Layer 375.

Various components of the present disclosure may be modeled using amodel-driven environment. For example, the model-driven framework orenvironment may allow the developer to use simple drag-and-droptechniques to develop pattern-based or freestyle user interfaces anddefine the flow of data between them. The result could be an efficient,customized, visually rich online experience. In some cases, thismodel-driven development may accelerate the application developmentprocess and foster business-user self-service. It further enablesbusiness analysts or IT developers to compose visually rich applicationsthat use analytic services, enterprise services, remote function calls(RFCs), APIs, and stored procedures. In addition, it may allow them toreuse existing applications and create content using a modeling processand a visual user interface instead of manual coding.

FIG. 5A depicts an example modeling environment 516, namely a modelingenvironment, in accordance with one embodiment of the presentdisclosure. Thus, as illustrated in FIG. 5A, such a modeling environment516 may implement techniques for decoupling models created duringdesign-time from the runtime environment. In other words, modelrepresentations for GUIs created in a design time environment aredecoupled from the runtime environment in which the GUIs are executed.Often in these environments, a declarative and executable representationfor GUIs for applications is provided that is independent of anyparticular runtime platform, GUI framework, device, or programminglanguage.

According to some embodiments, a modeler (or other analyst) may use themodel-driven modeling environment 516 to create pattern-based orfreestyle user interfaces using simple drag-and-drop services. Becausethis development may be model-driven, the modeler can typically composean application using models of business objects without having to writemuch, if any, code. In some cases, this example modeling environment 516may provide a personalized, secure interface that helps unify enterpriseapplications, information, and processes into a coherent, role-basedportal experience. Further, the modeling environment 516 may allow thedeveloper to access and share information and applications in acollaborative environment. In this way, virtual collaboration roomsallow developers to work together efficiently, regardless of where theyare located, and may enable powerful and immediate communication thatcrosses organizational boundaries while enforcing security requirements.Indeed, the modeling environment 516 may provide a shared set ofservices for finding, organizing, and accessing unstructured contentstored in third-party repositories and content management systems acrossvarious networks 312. Classification tools may automate the organizationof information, while subject-matter experts and content managers canpublish information to distinct user audiences. Regardless of theparticular implementation or architecture, this modeling environment 516may allow the developer to easily model hosted business objects 140using this model-driven approach.

In certain embodiments, the modeling environment 516 may implement orutilize a generic, declarative, and executable GUI language (generallydescribed as XGL). This example XGL is generally independent of anyparticular GUI framework or runtime platform. Further, XGL is normallynot dependent on characteristics of a target device on which the graphicuser interface is to be displayed and may also be independent of anyprogramming language. XGL is used to generate a generic representation(occasionally referred to as the XGL representation or XGL-compliantrepresentation) for a design-time model representation. The XGLrepresentation is thus typically a device-independent representation ofa GUI. The XGL representation is declarative in that the representationdoes not depend on any particular GUI framework, runtime platform,device, or programming language. The XGL representation can beexecutable and therefore can unambiguously encapsulate executionsemantics for the GUI described by a model representation. In short,models of different types can be transformed to XGL representations.

The XGL representation may be used for generating representations ofvarious different GUIs and supports various GUI features including fullwindowing and componentization support, rich data visualizations andanimations, rich modes of data entry and user interactions, and flexibleconnectivity to any complex application data services. While a specificembodiment of XGL is discussed, various other types of XGLs may also beused in alternative embodiments. In other words, it will be understoodthat XGL is used for example description only and may be read to includeany abstract or modeling language that can be generic, declarative, andexecutable.

Turning to the illustrated embodiment in FIG. 5A, modeling tool 340 maybe used by a GUI designer or business analyst during the applicationdesign phase to create a model representation 502 for a GUI application.It will be understood that modeling environment 516 may include or becompatible with various different modeling tools 340 used to generatemodel representation 502. This model representation 502 may be amachine-readable representation of an application or a domain specificmodel. Model representation 502 generally encapsulates various designparameters related to the GUI such as GUI components, dependenciesbetween the GUI components, inputs and outputs, and the like. Putanother way, model representation 502 provides a form in which the oneor more models can be persisted and transported, and possibly handled byvarious tools such as code generators, runtime interpreters, analysisand validation tools, merge tools, and the like. In one embodiment,model representation 502 maybe a collection of XML documents with awell-formed syntax.

Illustrated modeling environment 516 also includes an abstractrepresentation generator (or XGL generator) 504 operable to generate anabstract representation (for example, XGL representation orXGL-compliant representation) 506 based upon model representation 502.Abstract representation generator 504 takes model representation 502 asinput and outputs abstract representation 506 for the modelrepresentation. Model representation 502 may include multiple instancesof various forms or types depending on the tool/language used for themodeling. In certain cases, these various different modelrepresentations may each be mapped to one or more abstractrepresentations 506. Different types of model representations may betransformed or mapped to XGL representations. For each type of modelrepresentation, mapping rules may be provided for mapping the modelrepresentation to the XGL representation 506. Different mapping rulesmay be provided for mapping a model representation to an XGLrepresentation.

This XGL representation 506 that is created from a model representationmay then be used for processing in the runtime environment. For example,the XGL representation 506 may be used to generate a machine-executableruntime GUI (or some other runtime representation) that may be executedby a target device. As part of the runtime processing, the XGLrepresentation 506 may be transformed into one or more runtimerepresentations, which may indicate source code in a particularprogramming language, machine-executable code for a specific runtimeenvironment, executable GUI, and so forth, which may be generated forspecific runtime environments and devices. Since the XGL representation506, rather than the design-time model representation, is used by theruntime environment, the design-time model representation is decoupledfrom the runtime environment. The XGL representation 506 can thus serveas the common ground or interface between design-time user interfacemodeling tools and a plurality of user interface runtime frameworks. Itprovides a self-contained, closed, and deterministic definition of allaspects of a graphical user interface in a device-independent andprogramming-language independent manner. Accordingly, abstractrepresentation 506 generated for a model representation 502 is generallydeclarative and executable in that it provides a representation of theGUI of model representation 502 that is not dependent on any device orruntime platform, is not dependent on any programming language, andunambiguously encapsulates execution semantics for the GUI. Theexecution semantics may include, for example, identification of variouscomponents of the GUI, interpretation of connections between the variousGUI components, information identifying the order of sequencing ofevents, rules governing dynamic behavior of the GUI, rules governinghandling of values by the GUI, and the like. The abstract representation506 is also not GUI runtime-platform specific. The abstractrepresentation 506 provides a self-contained, closed, and deterministicdefinition of all aspects of a graphical user interface that is deviceindependent and language independent.

Abstract representation 506 is such that the appearance and executionsemantics of a GUI generated from the XGL representation workconsistently on different target devices irrespective of the GUIcapabilities of the target device and the target device platform. Forexample, the same XGL representation may be mapped to appropriate GUIson devices of differing levels of GUI complexity (i.e., the sameabstract representation may be used to generate a GUI for devices thatsupport simple GUIs and for devices that can support complex GUIs), theGUI generated by the devices are consistent with each other in theirappearance and behavior.

Abstract representation generator 504 may be configured to generateabstract representation 506 for models of different types, which may becreated using different modeling tools 340. It will be understood thatmodeling environment 516 may include some, none, or other sub-modules orcomponents as those shown in this example illustration. In other words,modeling environment 516 encompasses the design-time environment (withor without the abstract generator or the various representations), amodeling toolkit (such as 340) linked with a developer's space, or anyother appropriate software operable to decouple models created duringdesign-time from the runtime environment. Abstract representation 506provides an interface between the design time environment and theruntime environment. As shown, this abstract representation 506 may thenbe used by runtime processing.

As part of runtime processing, modeling environment 516 may includevarious runtime tools 508 and may generate different types of runtimerepresentations based upon the abstract representation 506. Examples ofruntime representations include device or language-dependent (orspecific) source code, runtime platform-specific machine-readable code,GUIs for a particular target device, and the like. The runtime tools 508may include compilers, interpreters, source code generators, and othersuch tools that are configured to generate runtime platform-specific ortarget device-specific runtime representations of abstractrepresentation 506. The runtime tool 508 may generate the runtimerepresentation from abstract representation 506 using specific rulesthat map abstract representation 506 to a particular type of runtimerepresentation. These mapping rules may be dependent on the type ofruntime tool, characteristics of the target device to be used fordisplaying the GUI, runtime platform, and/or other factors. Accordingly,mapping rules may be provided for transforming the abstractrepresentation 506 to any number of target runtime representationsdirected to one or more target GUI runtime platforms. For example,XGL-compliant code generators may conform to semantics of XGL, asdescribed below. XGL-compliant code generators may ensure that theappearance and behavior of the generated user interfaces is preservedacross a plurality of target GUI frameworks, while accommodating thedifferences in the intrinsic characteristics of each and alsoaccommodating the different levels of capability of target devices.

For example, as depicted in example FIG. 5A, an XGL-to-Java compiler508A may take abstract representation 506 as input and generate Javacode 510 for execution by a target device comprising a Java runtime 512.Java runtime 512 may execute Java code 510 to generate or display a GUI514 on a Java-platform target device. As another example, anXGL-to-Flash compiler 508B may take abstract representation 506 as inputand generate Flash code 526 for execution by a target device comprisinga Flash runtime 518. Flash runtime 518 may execute Flash code 516 togenerate or display a GUI 520 on a target device comprising a Flashplatform. As another example, an XGL-to-DHTML (dynamic HTML) interpreter508C may take abstract representation 506 as input and generate DHTMLstatements (instructions) on the fly which are then interpreted by aDHTML runtime 522 to generate or display a GUI 524 on a target devicecomprising a DHTML platform.

It should be apparent that abstract representation 506 may be used togenerate GUIs for Extensible Application Markup Language (XAML) orvarious other runtime platforms and devices. The same abstractrepresentation 506 may be mapped to various runtime representations anddevice-specific and runtime platform-specific GUIs. In general, in theruntime environment, machine executable instructions specific to aruntime environment may be generated based upon the abstractrepresentation 506 and executed to generate a GUI in the runtimeenvironment. The same XGL representation may be used to generate machineexecutable instructions specific to different runtime environments andtarget devices.

According to certain embodiments, the process of mapping a modelrepresentation 502 to an abstract representation 506 and mapping anabstract representation 506 to some runtime representation may beautomated. For example, design tools may automatically generate anabstract representation for the model representation using XGL and thenuse the XGL abstract representation to generate GUIs that are customizedfor specific runtime environments and devices. As previously indicated,mapping rules may be provided for mapping model representations to anXGL representation. Mapping rules may also be provided for mapping anXGL representation to a runtime platform-specific representation.

Since the runtime environment uses abstract representation 506 ratherthan model representation 502 for runtime processing, the modelrepresentation 502 that is created during design-time is decoupled fromthe runtime environment. Abstract representation 506 thus provides aninterface between the modeling environment and the runtime environment.As a result, changes may be made to the design time environment,including changes to model representation 502 or changes that affectmodel representation 502, generally to not substantially affect orimpact the runtime environment or tools used by the runtime environment.Likewise, changes may be made to the runtime environment generally tonot substantially affect or impact the design time environment. Adesigner or other developer can thus concentrate on the design aspectsand make changes to the design without having to worry about the runtimedependencies such as the target device platform or programming languagedependencies.

FIG. 5B depicts an example process for mapping a model representation502 to a runtime representation using the example modeling environment516 of FIG. 5A or some other modeling environment. Model representation502 may comprise one or more model components and associated propertiesthat describe a data object, such as hosted business objects andinterfaces. As described above, at least one of these model componentsis based on or otherwise associated with these hosted business objectsand interfaces. The abstract representation 506 is generated based uponmodel representation 502. Abstract representation 506 may be generatedby the abstract representation generator 504. Abstract representation506 comprises one or more abstract GUI components and propertiesassociated with the abstract GUI components. As part of generation ofabstract representation 506, the model GUI components and theirassociated properties from the model representation are mapped toabstract GUI components and properties associated with the abstract GUIcomponents. Various mapping rules may be provided to facilitate themapping. The abstract representation encapsulates both appearance andbehavior of a GUI. Therefore, by mapping model components to abstractcomponents, the abstract representation not only specifies the visualappearance of the GUI but also the behavior of the GUI, such as inresponse to events whether clicking/dragging or scrolling, interactionsbetween GUI components and such.

One or more runtime representations 550 a, including GUIs for specificruntime environment platforms, may be generated from abstractrepresentation 506. A device-dependent runtime representation may begenerated for a particular type of target device platform to be used forexecuting and displaying the GUI encapsulated by the abstractrepresentation. The GUIs generated from abstract representation 506 maycomprise various types of GUI elements such as buttons, windows,scrollbars, input boxes, etc. Rules may be provided for mapping anabstract representation to a particular runtime representation. Variousmapping rules may be provided for different runtime environmentplatforms.

Methods and systems consistent with the subject matter described hereinprovide and use interfaces 320 derived from the business object model318 suitable for use with more than one business area, for exampledifferent departments within a company such as finance, or marketing.Also, they are suitable across industries and across businesses.Interfaces 320 are used during an end-to-end business transaction totransfer business process information in an application-independentmanner. For example the interfaces can be used for fulfilling a salesorder.

1. Message Overview

To perform an end-to-end business transaction, consistent interfaces areused to create business documents that are sent within messages betweenheterogeneous programs or modules.

a) Message Categories

As depicted in FIG. 6, the communication between a sender 602 and arecipient 604 can be broken down into basic categories that describe thetype of the information exchanged and simultaneously suggest theanticipated reaction of the recipient 604. A message category is ageneral business classification for the messages. Communication issender-driven. In other words, the meaning of the message categories isestablished or formulated from the perspective of the sender 602. Themessage categories include information 606, notification 608, query 610,response 612, request 614, and confirmation 616.

(1) Information

Information 606 is a message sent from a sender 602 to a recipient 604concerning a condition or a statement of affairs. No reply toinformation is expected. Information 606 is sent to make businesspartners or business applications aware of a situation. Information 606is not compiled to be application-specific. Examples of “information”are an announcement, advertising, a report, planning information, and amessage to the business warehouse.

(2) Notification

A notification 608 is a notice or message that is geared to a service. Asender 602 sends the notification 608 to a recipient 604. No reply isexpected for a notification. For example, a billing notification relatesto the preparation of an invoice while a dispatched deliverynotification relates to preparation for receipt of goods.

(3) Query

A query 610 is a question from a sender 602 to a recipient 604 to whicha response 612 is expected. A query 610 implies no assurance orobligation on the part of the sender 602. Examples of a query 610 arewhether space is available on a specific flight or whether a specificproduct is available. These queries do not express the desire forreserving the flight or purchasing the product.

(4) Response

A response 612 is a reply to a query 610. The recipient 604 sends theresponse 612 to the sender 602. A response 612 generally implies noassurance or obligation on the part of the recipient 604. The sender 602is not expected to reply. Instead, the process is concluded with theresponse 612. Depending on the business scenario, a response 612 alsomay include a commitment, i.e., an assurance or obligation on the partof the recipient 604. Examples of responses 612 are a response statingthat space is available on a specific flight or that a specific productis available. With these responses, no reservation was made.

(5) Request

A request 614 is a binding requisition or requirement from a sender 602to a recipient 604. Depending on the business scenario, the recipient604 can respond to a request 614 with a confirmation 616. The request614 is binding on the sender 602. In making the request 614, the sender602 assumes, for example, an obligation to accept the services renderedin the request 614 under the reported conditions. Examples of a request614 are a parking ticket, a purchase order, an order for delivery and ajob application.

(6) Confirmation

A confirmation 616 is a binding reply that is generally made to arequest 614. The recipient 604 sends the confirmation 616 to the sender602. The information indicated in a confirmation 616, such as deadlines,products, quantities and prices, can deviate from the information of thepreceding request 614. A request 614 and confirmation 616 may be used innegotiating processes. A negotiating process can consist of a series ofseveral request 614 and confirmation 616 messages. The confirmation 616is binding on the recipient 604. For example, 100 units of X may beordered in a purchase order request; however, only the delivery of 80units is confirmed in the associated purchase order confirmation.

b) Message Choreography

A message choreography is a template that specifies the sequence ofmessages between business entities during a given transaction. Thesequence with the messages contained in it describes in general themessage “lifecycle” as it proceeds between the business entities. Ifmessages from a choreography are used in a business transaction, theyappear in the transaction in the sequence determined by thechoreography. This illustrates the template character of a choreography,i.e., during an actual transaction, it is not necessary for all messagesof the choreography to appear. Those messages that are contained in thetransaction, however, follow the sequence within the choreography. Abusiness transaction is thus a derivation of a message choreography. Thechoreography makes it possible to determine the structure of theindividual message types more precisely and distinguish them from oneanother.

2. Components of the Business Object Model

The overall structure of the business object model ensures theconsistency of the interfaces that are derived from the business objectmodel. The derivation ensures that the same business-related subjectmatter or concept is represented and structured in the same way in allinterfaces.

The business object model defines the business-related concepts at acentral location for a number of business transactions. In other words,it reflects the decisions made about modeling the business entities ofthe real world acting in business transactions across industries andbusiness areas. The business object model is defined by the businessobjects and their relationship to each other (the overall netstructure).

Each business object is generally a capsule with an internalhierarchical structure, behavior offered by its operations, andintegrity constraints. Business objects are semantically disjoint, i.e.,the same business information is represented once. In the businessobject model, the business objects are arranged in an orderingframework. From left to right, they are arranged according to theirexistence dependency to each other. For example, the customizingelements may be arranged on the left side of the business object model,the strategic elements may be arranged in the center of the businessobject model, and the operative elements may be arranged on the rightside of the business object model. Similarly, the business objects arearranged from the top to the bottom based on defined order of thebusiness areas, e.g., finance could be arranged at the top of thebusiness object model with CRM below finance and SRM below CRM.

To ensure the consistency of interfaces, the business object model maybe built using standardized data types as well as packages to grouprelated elements together, and package templates and entity templates tospecify the arrangement of packages and entities within the structure.

a) Data Types

Data types are used to type object entities and interfaces with astructure. This typing can include business semantic. Such data typesmay include those generally described at pages 96 through 1642 (whichare incorporated by reference herein) of U.S. patent application Ser.No. 11/803,178, filed on May 11, 2007 and entitled “Consistent Set OfInterfaces Derived From A Business Object Model”. For example, the datatype BusinessTransactionDocumentID is a unique identifier for a documentin a business transaction. Also, as an example, Data typeBusinessTransactionDocumentParty contains the information that isexchanged in business documents about a party involved in a businesstransaction, and includes the party's identity, the party's address, theparty's contact person and the contact person's address.BusinessTransactionDocumentParty also includes the role of the party,e.g., a buyer, seller, product recipient, or vendor.

The data types are based on Core Component Types (“CCTs”), whichthemselves are based on the World Wide Web Consortium (“W3C”) datatypes. “Global” data types represent a business situation that isdescribed by a fixed structure. Global data types include bothcontext-neutral generic data types (“GDTs”) and context-based contextdata types (“CDTs”). GDTs contain business semantics, but areapplication-neutral, i.e., without context. CDTs, on the other hand, arebased on GDTs and form either a use-specific view of the GDTs, or acontext-specific assembly of GDTs or CDTs. A message is typicallyconstructed with reference to a use and is thus a use-specific assemblyof GDTs and CDTs. The data types can be aggregated to complex datatypes.

To achieve a harmonization across business objects and interfaces, thesame subject matter is typed with the same data type. For example, thedata type “GeoCoordinates” is built using the data type “Measure” sothat the measures in a GeoCoordinate (i.e., the latitude measure and thelongitude measure) are represented the same as other “Measures” thatappear in the business object model.

b) Entities

Entities are discrete business elements that are used during a businesstransaction. Entities are not to be confused with business entities orthe components that interact to perform a transaction. Rather,“entities” are one of the layers of the business object model and theinterfaces. For example, a Catalogue entity is used in a CataloguePublication Request and a Purchase Order is used in a Purchase OrderRequest. These entities are created using the data types defined aboveto ensure the consistent representation of data throughout the entities.

c) Packages

Packages group the entities in the business object model and theresulting interfaces into groups of semantically associated information.Packages also may include “sub”-packages, i.e., the packages may benested.

Packages may group elements together based on different factors, such aselements that occur together as a rule with regard to a business-relatedaspect. For example, as depicted in FIG. 7, in a Purchase Order,different information regarding the purchase order, such as the type ofpayment 702, and payment card 704, are grouped together via thePaymentInformation package 700.

Packages also may combine different components that result in a newobject. For example, as depicted in FIG. 8, the components wheels 804,motor 806, and doors 808 are combined to form a composition “Car” 802.The “Car” package 800 includes the wheels, motor and doors as well asthe composition “Car.”

Another grouping within a package may be subtypes within a type. Inthese packages, the components are specialized forms of a genericpackage. For example, as depicted in FIG. 9, the components Car 904,Boat 906, and Truck 908 can be generalized by the generic term Vehicle902 in Vehicle package 900. Vehicle in this case is the generic package910, while Car 912, Boat 914, and Truck 916 are the specializations 918of the generalized vehicle 910.

Packages also may be used to represent hierarchy levels. For example, asdepicted in FIG. 10, the Item Package 1000 includes Item 1002 withsubitem xxx 1004, subitem yyy 1006, and subitem zzz 1008.

Packages can be represented in the XML schema as a comment. Oneadvantage of this grouping is that the document structure is easier toread and is more understandable. The names of these packages areassigned by including the object name in brackets with the suffix“Package.” For example, as depicted in FIG. 11, Party package 1100 isenclosed by <PartyPackage> 1102 and </PartyPackage> 1104. Party package1100 illustratively includes a Buyer Party 1106, identified by<BuyerParty> 1108 and </BuyerParty> 1110, and a Seller Party 1112,identified by <SellerParty> 1114 and </SellerParty>, etc.

d) Relationships

Relationships describe the interdependencies of the entities in thebusiness object model, and are thus an integral part of the businessobject model.

(1) Cardinality of Relationships

FIG. 12 depicts a graphical representation of the cardinalities betweentwo entities. The cardinality between a first entity and a second entityidentifies the number of second entities that could possibly exist foreach first entity. Thus, a 1:c cardinality 1200 between entities A 1202and X 1204 indicates that for each entity A 1202, there is either one orzero 1206 entity X 1204. A 1:1 cardinality 1208 between entities A 1210and X 1212 indicates that for each entity A 1210, there is exactly one1214 entity X 1212. A 1:n cardinality 1216 between entities A 1218 and X1220 indicates that for each entity A 1218, there are one or more 1222entity Xs 1220. A 1:cn cardinality 1224 between entities A 1226 and X1228 indicates that for each entity A 1226, there are any number 1230 ofentity Xs 1228 (i.e., 0 through n Xs for each A).

(2) Types of Relationships

(a) Composition

A composition or hierarchical relationship type is a strong whole-partrelationship which is used to describe the structure within an object.The parts, or dependent entities, represent a semantic refinement orpartition of the whole, or less dependent entity. For example, asdepicted in FIG. 13, the components 1302, wheels 1304, and doors 1306may be combined to form the composite 1300 “Car” 1308 using thecomposition 1310. FIG. 14 depicts a graphical representation of thecomposition 1410 between composite Car 1408 and components wheel 1404and door 1406.

(b) Aggregation

An aggregation or an aggregating relationship type is a weak whole-partrelationship between two objects. The dependent object is created by thecombination of one or several less dependent objects. For example, asdepicted in FIG. 15, the properties of a competitor product 1500 aredetermined by a product 1502 and a competitor 1504. A hierarchicalrelationship 1506 exists between the product 1502 and the competitorproduct 1500 because the competitor product 1500 is a component of theproduct 1502. Therefore, the values of the attributes of the competitorproduct 1500 are determined by the product 1502. An aggregatingrelationship 1508 exists between the competitor 1504 and the competitorproduct 1500 because the competitor product 1500 is differentiated bythe competitor 1504. Therefore the values of the attributes of thecompetitor product 1500 are determined by the competitor 1504.

(c) Association

An association or a referential relationship type describes arelationship between two objects in which the dependent object refers tothe less dependent object. For example, as depicted in FIG. 16, a person1600 has a nationality, and thus, has a reference to its country 1602 oforigin. There is an association 1604 between the country 1602 and theperson 1600.

The values of the attributes of the person 1600 are not determined bythe country 1602.

(3) Specialization

Entity types may be divided into subtypes based on characteristics ofthe entity types. For example, FIG. 17 depicts an entity type “vehicle”1700 specialized 1702 into subtypes “truck” 1704, “car” 1706, and “ship”1708. These subtypes represent different aspects or the diversity of theentity type.

Subtypes may be defined based on related attributes. For example,although ships and cars are both vehicles, ships have an attribute,“draft,” that is not found in cars. Subtypes also may be defined basedon certain methods that can be applied to entities of this subtype andthat modify such entities. For example, “drop anchor” can be applied toships. If outgoing relationships to a specific object are restricted toa subset, then a subtype can be defined which reflects this subset.

As depicted in FIG. 18, specializations may further be characterized ascomplete specializations 1800 or incomplete specializations 1802. Thereis a complete specialization 1800 where each entity of the generalizedtype belongs to at least one subtype. With an incomplete specialization1802, there is at least one entity that does not belong to a subtype.Specializations also may be disjoint 1804 or nondisjoint 1806. In adisjoint specialization 1804, each entity of the generalized typebelongs to a maximum of one subtype. With a nondisjoint specialization1806, one entity may belong to more than one subtype. As depicted inFIG. 18, four specialization categories result from the combination ofthe specialization characteristics.

e) Structural Patterns

(1) Item

An item is an entity type which groups together features of anotherentity type. Thus, the features for the entity type chart of accountsare grouped together to form the entity type chart of accounts item. Forexample, a chart of accounts item is a category of values or value flowsthat can be recorded or represented in amounts of money in accounting,while a chart of accounts is a superordinate list of categories ofvalues or value flows that is defined in accounting.

The cardinality between an entity type and its item is often either 1:nor 1:cn. For example, in the case of the entity type chart of accounts,there is a hierarchical relationship of the cardinality 1:n with theentity type chart of accounts item since a chart of accounts has atleast one item in all cases.

(2) Hierarchy

A hierarchy describes the assignment of subordinate entities tosuperordinate entities and vice versa, where several entities of thesame type are subordinate entities that have, at most, one directlysuperordinate entity. For example, in the hierarchy depicted in FIG. 19,entity B 1902 is subordinate to entity A 1900, resulting in therelationship (A,B) 1912. Similarly, entity C 1904 is subordinate toentity A 1900, resulting in the relationship (A,C) 1914. Entity D 1906and entity E 1908 are subordinate to entity B 1902, resulting in therelationships (B,D) 1916 and (B,E) 1918, respectively. Entity F 1910 issubordinate to entity C 1904, resulting in the relationship (C,F) 1920.

Because each entity has at most one superordinate entity, thecardinality between a subordinate entity and its superordinate entity is1:c. Similarly, each entity may have 0, 1 or many subordinate entities.Thus, the cardinality between a superordinate entity and its subordinateentity is 1:cn. FIG. 20 depicts a graphical representation of a ClosingReport Structure Item hierarchy 2000 for a Closing Report Structure Item2002. The hierarchy illustrates the 1:c cardinality 2004 between asubordinate entity and its superordinate entity, and the 1:cncardinality 2006 between a superordinate entity and its subordinateentity.

3. Creation of the business object Model

FIGS. 21A-B depict the steps performed using methods and systemsconsistent with the subject matter described herein to create a businessobject model. Although some steps are described as being performed by acomputer, these steps may alternatively be performed manually, orcomputer-assisted, or any combination thereof. Likewise, although somesteps are described as being performed by a computer, these steps mayalso be computer-assisted, or performed manually, or any combinationthereof.

As discussed above, the designers create message choreographies thatspecify the sequence of messages between business entities during atransaction. After identifying the messages, the developers identify thefields contained in one of the messages (step 2100, FIG. 21A). Thedesigners then determine whether each field relates to administrativedata or is part of the object (step 2102). Thus, the first eleven fieldsidentified below in the left column are related to administrative data,while the remaining fields are part of the object.

MessageID Admin ReferenceID CreationDate SenderID AdditionalSenderIDContactPersonID SenderAddress RecipientID AdditionalRecipientIDContactPersonID RecipientAddress ID Main Object AdditionalID PostingDateLastChangeDate AcceptanceStatus Note CompleteTransmission IndicatorBuyer BuyerOrganisationName Person Name FunctionalTitle DepartmentNameCountryCode StreetPostalCode POBox Postal Code Company Postal Code CityName DistrictName PO Box ID PO Box Indicator PO Box Country Code PO BoxRegion Code PO Box City Name Street Name House ID Building ID Floor IDRoom ID Care Of Name AddressDescription Telefonnumber MobileNumberFacsimile Email Seller SellerAddress Location LocationTypeDeliveryItemGroupID DeliveryPriority DeliveryCondition TransferLocationNumberofPartialDelivery QuantityTolerance MaximumLeadTimeTransportServiceLevel TranportCondition TransportDescriptionCashDiscountTerms PaymentForm PaymentCardID PaymentCardReferenceIDSequenceID Holder ExpirationDate AttachmentID AttachmentFilenameDescriptionofMessage ConfirmationDescriptionof Message FollowUpActivityItemID ParentItemID HierarchyType ProductID ProductType ProductNoteProductCategoryID Amount BaseQuantity ConfirmedAmountConfirmedBaseQuantity ItemBuyer ItemBuyerOrganisationName Person NameFunctionalTitle DepartmentName CountryCode StreetPostalCode POBox PostalCode Company Postal Code City Name DistrictName PO Box ID PO BoxIndicator PO Box Country Code PO Box Region Code PO Box City Name StreetName House ID Building ID Floor ID Room ID Care Of NameAddressDescription Telefonnumber MobilNumber Facsimile Email ItemSellerItemSellerAddress ItemLocation ItemLocationType ItemDeliveryItemGroupIDItemDeliveryPriority ItemDeliveryCondition ItemTransferLocationItemNumberofPartialDelivery ItemQuantityTolerance ItemMaximumLeadTimeItemTransportServiceLevel ItemTranportCondition ItemTransportDescriptionContractReference QuoteReference CatalogueReference ItemAttachmentIDItemAttachmentFilename ItemDescription ScheduleLineID DeliveryPeriodQuantity ConfirmedScheduleLineID ConfirmedDeliveryPeriodConfirmedQuantity

Next, the designers determine the proper name for the object accordingto the ISO 11179 naming standards (step 2104). In the example above, theproper name for the “Main Object” is “Purchase Order.” After naming theobject, the system that is creating the business object model determineswhether the object already exists in the business object model (step2106). If the object already exists, the system integrates newattributes from the message into the existing object (step 2108), andthe process is complete.

If at step 2106 the system determines that the object does not exist inthe business object model, the designers model the internal objectstructure (step 2110). To model the internal structure, the designersdefine the components. For the above example, the designers may definethe components identified below.

ID Purchase AdditionalID Order PostingDate LastChangeDateAcceptanceStatus Note CompleteTransmission Indicator Buyer BuyerBuyerOrganisationName Person Name FunctionalTitle DepartmentNameCountryCode StreetPostalCode POBox Postal Code Company Postal Code CityName DistrictName PO Box ID PO Box Indicator PO Box Country Code PO BoxRegion Code PO Box City Name Street Name House ID Building ID Floor IDRoom ID Care Of Name AddressDescription Telefonnumber MobileNumberFacsimile Email Seller Seller SellerAddress Location LocationLocationType DeliveryItemGroupID Delivery- DeliveryPriority TermsDeliveryCondition TransferLocation NumberofPartialDeliveryQuantityTolerance MaximumLeadTime TransportServiceLevelTranportCondition TransportDescription CashDiscountTerms PaymentFormPayment PaymentCardID PaymentCardReferenceID SequenceID HolderExpirationDate AttachmentID AttachmentFilename DescriptionofMessageConfirmationDescriptionof Message FollowUpActivity ItemID PurchaseParentItemID Order HierarchyType Item ProductID Product ProductTypeProductNote ProductCategoryID ProductCategory Amount BaseQuantityConfirmedAmount ConfirmedBaseQuantity ItemBuyer BuyerItemBuyerOrganisation Name Person Name FunctionalTitle DepartmentNameCountryCode StreetPostalCode POBox Postal Code Company Postal Code CityName DistrictName PO Box ID PO Box Indicator PO Box Country Code PO BoxRegion Code PO Box City Name Street Name House ID Building ID Floor IDRoom ID Care Of Name AddressDescription Telefonnumber MobilNumberFacsimile Email ItemSeller Seller ItemSellerAddress ItemLocationLocation ItemLocationType ItemDeliveryItemGroupID ItemDeliveryPriorityItemDeliveryCondition ItemTransferLocation ItemNumberofPartial DeliveryItemQuantityTolerance ItemMaximumLeadTime ItemTransportServiceLevelItemTranportCondition ItemTransportDescription ContractReferenceContract QuoteReference Quote CatalogueReference CatalogueItemAttachmentID ItemAttachmentFilename ItemDescription ScheduleLineIDDeliveryPeriod Quantity ConfirmedScheduleLineID ConfirmedDeliveryPeriodConfirmedQuantity

During the step of modeling the internal structure, the designers alsomodel the complete internal structure by identifying the compositions ofthe components and the corresponding cardinalities, as shown below.

PurchaseOrder 1 Buyer 0 . . . 1 Address 0 . . . 1 ContactPerson 0 . . .1 Address 0 . . . 1 Seller 0 . . . 1 Location 0 . . . 1 Address 0 . . .1 DeliveryTerms 0 . . . 1 Incoterms 0 . . . 1 PartialDelivery 0 . . . 1QuantityTolerance 0 . . . 1 Transport 0 . . . 1 CashDiscount 0 . . . 1Terms MaximumCashDiscount 0 . . . 1 NormalCashDiscount 0 . . . 1PaymentForm 0 . . . 1 PaymentCard 0 . . . 1 Attachment 0 . . . nDescription 0 . . . 1 Confirmation 0 . . . 1 Description Item 0 . . . nHierarchyRelationship 0 . . . 1 Product 0 . . . 1 ProductCategory 0 . .. 1 Price 0 . . . 1 NetunitPrice 0 . . . 1 ConfirmedPrice 0 . . . 1NetunitPrice 0 . . . 1 Buyer 0 . . . 1 Seller 0 . . . 1 Location 0 . . .1 DeliveryTerms 0 . . . 1 Attachment 0 . . . n Description 0 . . . 1ConfirmationDescription 0 . . . 1 ScheduleLine 0 . . . n DeliveryPeriod1 ConfirmedScheduleLine 0 . . . n

After modeling the internal object structure, the developers identifythe subtypes and generalizations for all objects and components (step2112). For example, the Purchase Order may have subtypes Purchase OrderUpdate, Purchase Order Cancellation and Purchase Order Information.Purchase Order Update may include Purchase Order Request, Purchase OrderChange, and Purchase Order Confirmation. Moreover, Party may beidentified as the generalization of Buyer and Seller. The subtypes andgeneralizations for the above example are shown below.

Purchase 1 Order PurchaseOrder Update PurchaseOrder RequestPurchaseOrder Change PurchaseOrder Confirmation PurchaseOrderCancellation PurchaseOrder Information Party BuyerParty 0 . . . 1Address 0 . . . 1 ContactPerson 0 . . . 1 Address 0 . . . 1 SellerParty0 . . . 1 Location ShipToLocation 0 . . . 1 Address 0 . . . 1ShipFromLocation 0 . . . 1 Address 0 . . . 1 DeliveryTerms 0 . . . 1Incoterms 0 . . . 1 PartialDelivery 0 . . . 1 QuantityTolerance 0 . . .1 Transport 0 . . . 1 CashDiscount 0 . . . 1 Terms MaximumCash Discount0 . . . 1 NormalCashDiscount 0 . . . 1 PaymentForm 0 . . . 1 PaymentCard0 . . . 1 Attachment 0 . . . n Description 0 . . . 1 Confirmation 0 . .. 1 Description Item 0 . . . n HierarchyRelationship 0 . . . 1 Product 0. . . 1 ProductCategory 0 . . . 1 Price 0 . . . 1 NetunitPrice 0 . . . 1ConfirmedPrice 0 . . . 1 NetunitPrice 0 . . . 1 Party BuyerParty 0 . . .1 SellerParty 0 . . . 1 Location ShipTo 0 . . . 1 Location ShipFrom 0 .. . 1 Location DeliveryTerms 0 . . . 1 Attachment 0 . . . n Description0 . . . 1 Confirmation 0 . . . 1 Description ScheduleLine 0 . . . nDelivery 1 Period ConfirmedScheduleLine 0 . . . n

After identifying the subtypes and generalizations, the developersassign the attributes to these components (step 2114). The attributesfor a portion of the components are shown below.

Purchase 1 Order ID 1 SellerID 0 . . . 1 BuyerPosting 0 . . . 1 DateTimeBuyerLast 0 . . . 1 ChangeDate Time SellerPosting 0 . . . 1 DateTimeSellerLast 0 . . . 1 ChangeDate Time Acceptance 0 . . . 1 StatusCodeNote 0 . . . 1 ItemList 0 . . . 1 Complete Transmission IndicatorBuyerParty 0 . . . 1 StandardID 0 . . . n BuyerID 0 . . . 1 SellerID 0 .. . 1 Address 0 . . . 1 ContactPerson 0 . . . 1 BuyerID 0 . . . 1SellerID 0 . . . 1 Address 0 . . . 1 SellerParty 0 . . . 1 Product 0 . .. 1 RecipientParty VendorParty 0 . . . 1 Manufacturer 0 . . . 1 PartyBillToParty 0 . . . 1 PayerParty 0 . . . 1 CarrierParty 0 . . . 1 ShipTo0 . . . 1 Location StandardID 0 . . . n BuyerID 0 . . . 1 SellerID 0 . .. 1 Address 0 . . . 1 ShipFrom 0 . . . 1 Location

The system then determines whether the component is one of the objectnodes in the business object model (step 2116, FIG. 21B). If the systemdetermines that the component is one of the object nodes in the businessobject model, the system integrates a reference to the correspondingobject node from the business object model into the object (step 2118).In the above example, the system integrates the reference to the Buyerparty represented by an ID and the reference to the ShipToLocationrepresented by an into the object, as shown below. The attributes thatwere formerly located in the PurchaseOrder object are now assigned tothe new found object party. Thus, the attributes are removed from thePurchaseOrder object.

PurchaseOrder ID SellerID BuyerPostingDateTime BuyerLastChangeDateTimeSellerPostingDateTime SellerLastChangeDateTime AcceptanceStatusCode NoteItemListComplete TransmissionIndicator BuyerParty ID SellerPartyProductRecipientParty VendorParty ManufacturerParty BillToPartyPayerParty CarrierParty ShipToLocation ID ShipFromLocation

During the integration step, the designers classify the relationship(i.e., aggregation or association) between the object node and theobject being integrated into the business object model. The system alsointegrates the new attributes into the object node (step 2120). If atstep 2116, the system determines that the component is not in thebusiness object model, the system adds the component to the businessobject model (step 2122).

Regardless of whether the component was in the business object model atstep 2116, the next step in creating the business object model is to addthe integrity rules (step 2124). There are several levels of integrityrules and constraints which should be described. These levels includeconsistency rules between attributes, consistency rules betweencomponents, and consistency rules to other objects. Next, the designersdetermine the services offered, which can be accessed via interfaces(step 2126). The services offered in the example above includePurchaseOrderCreateRequest, PurchaseOrderCancellationRequest, andPurchaseOrderReleaseRequest. The system then receives an indication ofthe location for the object in the business object model (step 2128).After receiving the indication of the location, the system integratesthe object into the business object model (step 2130).

4. Structure of the business object Model

The business object model, which serves as the basis for the process ofgenerating consistent interfaces, includes the elements contained withinthe interfaces. These elements are arranged in a hierarchical structurewithin the business object model.

5. Interfaces Derived from business object Model

Interfaces are the starting point of the communication between twobusiness entities. The structure of each interface determines how onebusiness entity communicates with another business entity. The businessentities may act as a unified whole when, based on the businessscenario, the business entities know what an interface contains from abusiness perspective and how to fill the individual elements or fieldsof the interface. As illustrated in FIG. 27A, communication betweencomponents takes place via messages that contain business documents(e.g., business document 27002). The business document 27002 ensures aholistic business-related understanding for the recipient of themessage. The business documents are created and accepted or consumed byinterfaces, specifically by inbound and outbound interfaces. Theinterface structure and, hence, the structure of the business documentare derived by a mapping rule. This mapping rule is known as“hierarchization.” An interface structure thus has a hierarchicalstructure created based on the leading business object 27000. Theinterface represents a usage-specific, hierarchical view of theunderlying usage-neutral object model.

As illustrated in FIG. 27B, several business document objects 27006,27008, and 27010 as overlapping views may be derived for a given leadingobject 27004. Each business document object results from the objectmodel by hierarchization.

To illustrate the hierarchization process, FIG. 27C depicts an exampleof an object model 27012 (i.e., a portion of the business object model)that is used to derive a service operation signature (business documentobject structure). As depicted, leading object X 27014 in the objectmodel 27012 is integrated in a net of object A 27016, object B 27018,and object C 27020. Initially, the parts of the leading object 27014that are required for the business object document are adopted. In onevariation, all parts required for a business document object are adoptedfrom leading object 27014 (making such an operation a maximal serviceoperation). Based on these parts, the relationships to the superordinateobjects (i.e., objects A, B, and C from which object X depends) areinverted. In other words, these objects are adopted as dependent orsubordinate objects in the new business document object.

For example, object A 27016, object B 27018, and object C 27020 haveinformation that characterize object X. Because object A 27016, object B27018, and object C 27020 are superordinate to leading object X 27014,the dependencies of these relationships change so that object A 27016,object B 27018, and object C 27020 become dependent and subordinate toleading object X 27014. This procedure is known as “derivation of thebusiness document object by hierarchization.”

Business-related objects generally have an internal structure (parts).This structure can be complex and reflect the individual parts of anobject and their mutual dependency. When creating the operationsignature, the internal structure of an object is strictly hierarchized.Thus, dependent parts keep their dependency structure, and relationshipsbetween the parts within the object that do not represent thehierarchical structure are resolved by prioritizing one of therelationships.

Relationships of object X to external objects that are referenced andwhose information characterizes object X are added to the operationsignature. Such a structure can be quite complex (see, for example, FIG.27D). The cardinality to these referenced objects is adopted as 1:1 or1:C, respectively. By this, the direction of the dependency changes. Therequired parts of this referenced object are adopted identically, bothin their cardinality and in their dependency arrangement.

The newly created business document object contains all requiredinformation, including the incorporated master data information of thereferenced objects. As depicted in FIG. 27D, components Xi in leadingobject X 27022 are adopted directly. The relationship of object X 27022to object A 27024, object B 27028, and object C 27026 are inverted, andthe parts required by these objects are added as objects that dependfrom object X 27022. As depicted, all of object A 27024 is adopted. B3and B4 are adopted from object B 27028, but B1 is not adopted. Fromobject C 27026, C2 and C1 are adopted, but C3 is not adopted.

FIG. 27E depicts the business document object X 27030 created by thishierarchization process. As shown, the arrangement of the elementscorresponds to their dependency levels, which directly leads to acorresponding representation as an XML structure 27032.

The following provides certain rules that can be adopted singly or incombination with regard to the hierarchization process. A businessdocument object always refers to a leading business document object andis derived from this object. The name of the root entity in the businessdocument entity is the name of the business object or the name of aspecialization of the business object or the name of a service specificview onto the business object. The nodes and elements of the businessobject that are relevant (according to the semantics of the associatedmessage type) are contained as entities and elements in the businessdocument object.

The name of a business document entity is predefined by the name of thecorresponding business object node. The name of the superordinate entityis not repeated in the name of the business document entity. The “full”semantic name results from the concatenation of the entity names alongthe hierarchical structure of the business document object.

The structure of the business document object is, except for deviationsdue to hierarchization, the same as the structure of the businessobject. The cardinalities of the business document object nodes andelements are adopted identically or more restrictively to the businessdocument object. An object from which the leading business object isdependent can be adopted to the business document object. For thisarrangement, the relationship is inverted, and the object (or its parts,respectively) are hierarchically subordinated in the business documentobject.

Nodes in the business object representing generalized businessinformation can be adopted as explicit entities to the business documentobject (generally speaking, multiply TypeCodes out). When this adoptionoccurs, the entities are named according to their more specific semantic(name of TypeCode becomes prefix). Party nodes of the business objectare modeled as explicit entities for each party role in the businessdocument object. These nodes are given the name <Prefix><PartyRole>Party, for example, BuyerParty, ItemBuyerParty. BTDReference nodesare modeled as separate entities for each reference type in the businessdocument object. These nodes are given the name<Qualifier><BO><Node>Reference, for example SalesOrderReference,OriginSalesOrderReference, SalesOrderltemReference. A product node inthe business object comprises all of the information on the Product,ProductCategory, and Batch. This information is modeled in the businessdocument object as explicit entities for Product, ProductCategory, andBatch.

Entities which are connected by a 1:1 relationship as a result ofhierarchization can be combined to a single entity, if they aresemantically equivalent. Such a combination can often occurs if a nodein the business document object that results from an assignment node isremoved because it does not have any elements.

The message type structure is typed with data types. Elements are typedby GDTs according to their business objects. Aggregated levels are typedwith message type specific data types (Intermediate Data Types), withtheir names being built according to the corresponding paths in themessage type structure. The whole message type structured is typed by amessage data type with its name being built according to the root entitywith the suffix “Message”. For the message type, the message category(e.g., information, notification, query, response, request,confirmation, etc.) is specified according to the suited transactioncommunication pattern.

In one variation, the derivation by hierarchization can be initiated byspecifying a leading business object and a desired view relevant for aselected service operation. This view determines the business documentobject. The leading business object can be the source object, the targetobject, or a third object. Thereafter, the parts of the business objectrequired for the view are determined. The parts are connected to theroot node via a valid path along the hierarchy. Thereafter, one or moreindependent objects (object parts, respectively) referenced by theleading object which are relevant for the service may be determined(provided that a relationship exists between the leading object and theone or more independent objects).

Once the selection is finalized, relevant nodes of the leading objectnode that are structurally identical to the message type structure canthen be adopted. If nodes are adopted from independent objects or objectparts, the relationships to such independent objects or object parts areinverted. Linearization can occur such that a business object nodecontaining certain TypeCodes is represented in the message typestructure by explicit entities (an entity for each value of theTypeCode). The structure can be reduced by checking all 1:1cardinalities in the message type structure. Entities can be combined ifthey are semantically equivalent, one of the entities carries noelements, or an entity solely results from an n:m assignment in thebusiness object.

After the hierarchization is completed, information regardingtransmission of the business document object (e.g.,CompleteTransmissionIndicator, ActionCodes, message category, etc.) canbe added. A standardized message header can be added to the message typestructure and the message structure can be typed. Additionally, themessage category for the message type can be designated.

Invoice Request and Invoice Confirmation are examples of interfaces.These invoice interfaces are used to exchange invoices and invoiceconfirmations between an invoicing party and an invoice recipient (suchas between a seller and a buyer) in a B2B process. Companies can createinvoices in electronic as well as in paper form. Traditional methods ofcommunication, such as mail or fax, for invoicing are cost intensive,prone to error, and relatively slow, since the data is recordedmanually. Electronic communication eliminates such problems. Themotivating business scenarios for the Invoice Request and InvoiceConfirmation interfaces are the Procure to Stock (PTS) and Sell fromStock (SFS) scenarios. In the PTS scenario, the parties use invoiceinterfaces to purchase and settle goods. In the SFS scenario, theparties use invoice interfaces to sell and invoice goods. The invoiceinterfaces directly integrate the applications implementing them andalso form the basis for mapping data to widely-used XML standard formatssuch as RosettaNet, PIDX, xCBL, and CIDX.

The invoicing party may use two different messages to map a B2Binvoicing process: (1) the invoicing party sends the message typeInvoiceRequest to the invoice recipient to start a new invoicingprocess; and (2) the invoice recipient sends the message typeInvoiceConfirmation to the invoicing party to confirm or reject anentire invoice or to temporarily assign it the status “pending.”

An InvoiceRequest is a legally binding notification of claims orliabilities for delivered goods and rendered services—usually, a paymentrequest for the particular goods and services.

The message type InvoiceRequest is based on the message data typeInvoiceMessage. The InvoiceRequest message (as defined) transfersinvoices in the broader sense. This includes the specific invoice(request to settle a liability), the debit memo, and the credit memo.

InvoiceConfirmation is a response sent by the recipient to the invoicingparty confirming or rejecting the entire invoice received or statingthat it has been assigned temporarily the status “pending.” The messagetype InvoiceConfirmation is based on the message data typeInvoiceMessage. An InvoiceConfirmation is not mandatory in a B2Binvoicing process, however, it automates collaborative processes anddispute management.

Usually, the invoice is created after it has been confirmed that thegoods were delivered or the service was provided. The invoicing party(such as the seller) starts the invoicing process by sending anInvoiceRequest message. Upon receiving the InvoiceRequest message, theinvoice recipient (for instance, the buyer) can use theInvoiceConfirmation message to completely accept or reject the invoicereceived or to temporarily assign it the status “pending.” TheInvoiceConfirmation is not a negotiation tool (as is the case in ordermanagement), since the options available are either to accept or rejectthe entire invoice. The invoice data in the InvoiceConfirmation messagemerely confirms that the invoice has been forwarded correctly and doesnot communicate any desired changes to the invoice. Therefore, theInvoiceConfirmation includes the precise invoice data that the invoicerecipient received and checked. If the invoice recipient rejects aninvoice, the invoicing party can send a new invoice after checking thereason for rejection (AcceptanceStatus and ConfirmationDescription atInvoice and InvoiceItem level). If the invoice recipient does notrespond, the invoice is generally regarded as being accepted and theinvoicing party can expect payment.

FIGS. 22A-F depict a flow diagram of the steps performed by methods andsystems consistent with the subject matter described herein to generatean interface from the business object model. Although described as beingperformed by a computer, these steps may alternatively be performedmanually, or using any combination thereof. The process begins when thesystem receives an indication of a package template from the designer,i.e., the designer provides a package template to the system (step2200).

Package templates specify the arrangement of packages within a businesstransaction document. Package templates are used to define the overallstructure of the messages sent between business entities. Methods andsystems consistent with the subject matter described herein use packagetemplates in conjunction with the business object model to derive theinterfaces.

The system also receives an indication of the message type from thedesigner (step 2202). The system selects a package from the packagetemplate (step 2204), and receives an indication from the designerwhether the package is required for the interface (step 2206). If thepackage is not required for the interface, the system removes thepackage from the package template (step 2208). The system then continuesthis analysis for the remaining packages within the package template(step 2210).

If, at step 2206, the package is required for the interface, the systemcopies the entity template from the package in the business object modelinto the package in the package template (step 2212, FIG. 22B). Thesystem determines whether there is a specialization in the entitytemplate (step 2214). If the system determines that there is aspecialization in the entity template, the system selects a subtype forthe specialization (step 2216). The system may either select the subtypefor the specialization based on the message type, or it may receive thisinformation from the designer. The system then determines whether thereare any other specializations in the entity template (step 2214). Whenthe system determines that there are no specializations in the entitytemplate, the system continues this analysis for the remaining packageswithin the package template (step 2210, FIG. 22A).

At step 2210, after the system completes its analysis for the packageswithin the package template, the system selects one of the packagesremaining in the package template (step 2218, FIG. 22C), and selects anentity from the package (step 2220). The system receives an indicationfrom the designer whether the entity is required for the interface (step2222). If the entity is not required for the interface, the systemremoves the entity from the package template (step 2224). The systemthen continues this analysis for the remaining entities within thepackage (step 2226), and for the remaining packages within the packagetemplate (step 2228).

If, at step 2222, the entity is required for the interface, the systemretrieves the cardinality between a superordinate entity and the entityfrom the business object model (step 2230, FIG. 22D). The system alsoreceives an indication of the cardinality between the superordinateentity and the entity from the designer (step 2232). The system thendetermines whether the received cardinality is a subset of the businessobject model cardinality (step 2234). If the received cardinality is nota subset of the business object model cardinality, the system sends anerror message to the designer (step 2236). If the received cardinalityis a subset of the business object model cardinality, the system assignsthe received cardinality as the cardinality between the superordinateentity and the entity (step 2238). The system then continues thisanalysis for the remaining entities within the package (step 2226, FIG.22C), and for the remaining packages within the package template (step2228).

The system then selects a leading object from the package template (step2240, FIG. 22E). The system determines whether there is an entitysuperordinate to the leading object (step 2242). If the systemdetermines that there is an entity superordinate to the leading object,the system reverses the direction of the dependency (step 2244) andadjusts the cardinality between the leading object and the entity (step2246). The system performs this analysis for entities that aresuperordinate to the leading object (step 2242). If the systemdetermines that there are no entities superordinate to the leadingobject, the system identifies the leading object as analyzed (step2248).

The system then selects an entity that is subordinate to the leadingobject (step 2250, FIG. 22F). The system determines whether anynon-analyzed entities are superordinate to the selected entity (step2252). If a non-analyzed entity is superordinate to the selected entity,the system reverses the direction of the dependency (step 2254) andadjusts the cardinality between the selected entity and the non-analyzedentity (step 2256). The system performs this analysis for non-analyzedentities that are superordinate to the selected entity (step 2252). Ifthe system determines that there are no non-analyzed entitiessuperordinate to the selected entity, the system identifies the selectedentity as analyzed (step 2258), and continues this analysis for entitiesthat are subordinate to the leading object (step 2260). After thepackages have been analyzed, the system substitutes theBusinessTransactionDocument (“BTD”) in the package template with thename of the interface (step 2262). This includes the “BTD” in theBTDItem package and the “BTD” in the BTDItemScheduleLine package.

6. Use of an Interface

The XI stores the interfaces (as an interface type). At runtime, thesending party's program instantiates the interface to create a businessdocument, and sends the business document in a message to the recipient.The messages are preferably defined using XML. In the example depictedin FIG. 23, the Buyer 2300 uses an application 2306 in its system toinstantiate an interface 2308 and create an interface object or businessdocument object 2310. The Buyer's application 2306 uses data that is inthe sender's component-specific structure and fills the businessdocument object 2310 with the data. The Buyer's application 2306 thenadds message identification 2312 to the business document and places thebusiness document into a message 2302. The Buyer's application 2306sends the message 2302 to the Vendor 2304. The Vendor 2304 uses anapplication 2314 in its system to receive the message 2302 and store thebusiness document into its own memory. The Vendor's application 2314unpacks the message 2302 using the corresponding interface 2316 storedin its XI to obtain the relevant data from the interface object orbusiness document object 2318.

From the component's perspective, the interface is represented by aninterface proxy 2400, as depicted in FIG. 24. The proxies 2400 shieldthe components 2402 of the sender and recipient from the technicaldetails of sending messages 2404 via XI. In particular, as depicted inFIG. 25, at the sending end, the Buyer 2500 uses an application 2510 inits system to call an implemented method 2512, which generates theoutbound proxy 2506. The outbound proxy 2506 parses the internal datastructure of the components and converts them to the XML structure inaccordance with the business document object. The outbound proxy 2506packs the document into a message 2502. Transport, routing and mappingthe XML message to the recipient 28304 is done by the routing system(XI, modeling environment 516, etc.).

When the message arrives, the recipient's inbound proxy 2508 calls itscomponent-specific method 2514 for creating a document. The proxy 2508at the receiving end downloads the data and converts the XML structureinto the internal data structure of the recipient component 2504 forfurther processing.

As depicted in FIG. 26A, a message 2600 includes a message header 2602and a business document 2604. The message 2600 also may include anattachment 2606. For example, the sender may attach technical drawings,detailed specifications or pictures of a product to a purchase order forthe product. The business document 2604 includes a business documentmessage header 2608 and the business document object 2610. The businessdocument message header 2608 includes administrative data, such as themessage ID and a message description. As discussed above, the structure2612 of the business document object 2610 is derived from the businessobject model 2614. Thus, there is a strong correlation between thestructure of the business document object and the structure of thebusiness object model. The business document object 2610 forms the coreof the message 2600.

In collaborative processes as well as Q&A processes, messages shouldrefer to documents from previous messages. A simple business documentobject ID or object ID is insufficient to identify individual messagesuniquely because several versions of the same business document objectcan be sent during a transaction. A business document object ID with aversion number also is insufficient because the same version of abusiness document object can be sent several times. Thus, messagesrequire several identifiers during the course of a transaction.

As depicted in FIG. 26B, the message header 2618 in message 2616includes a technical ID (“ID4”) 2622 that identifies the address for acomputer to route the message. The sender's system manages the technicalID 2622.

The administrative information in the business document message header2624 of the payload or business document 2620 includes aBusinessDocumentMessageID (“ID3”) 2628. The business entity or component2632 of the business entity manages and sets theBusinessDocumentMessageID 2628. The business entity or component 2632also can refer to other business documents using theBusinessDocumentMessageID 2628. The receiving component 2632 requires noknowledge regarding the structure of this ID. TheBusinessDocumentMessageID 2628 is, as an ID, unique. Creation of amessage refers to a point in time. No versioning is typically expressedby the ID. Besides the BusinessDocumentMessageID 2628, there also is abusiness document object ID 2630, which may include versions.

The component 2632 also adds its own component object ID 2634 when thebusiness document object is stored in the component. The componentobject ID 2634 identifies the business document object when it is storedwithin the component. However, not all communication partners may beaware of the internal structure of the component object ID 2634. Somecomponents also may include a versioning in their ID 2634.

7. Use of Interfaces Across Industries

Methods and systems consistent with the subject matter described hereinprovide interfaces that may be used across different business areas fordifferent industries. Indeed, the interfaces derived using methods andsystems consistent with the subject matter described herein may bemapped onto the interfaces of different industry standards. Unlike theinterfaces provided by any given standard that do not include theinterfaces required by other standards, methods and systems consistentwith the subject matter described herein provide a set of consistentinterfaces that correspond to the interfaces provided by differentindustry standards. Due to the different fields provided by eachstandard, the interface from one standard does not easily map ontoanother standard. By comparison, to map onto the different industrystandards, the interfaces derived using methods and systems consistentwith the subject matter described herein include most of the fieldsprovided by the interfaces of different industry standards. Missingfields may easily be included into the business object model. Thus, byderivation, the interfaces can be extended consistently by these fields.Thus, methods and systems consistent with the subject matter describedherein provide consistent interfaces or services that can be used acrossdifferent industry standards.

For example, FIG. 28 illustrates an example method 2800 for serviceenabling. In this example, the enterprise services infrastructure mayoffer one common and standard-based service infrastructure. Further, onecentral enterprise services repository may support uniform servicedefinition, implementation and usage of services for user interface, andcross-application communication. In step 2801, a business object isdefined via a process component model in a process modeling phase. Next,in step 2802, the business object is designed within an enterpriseservices repository. For example, FIG. 29 provides a graphicalrepresentation of one of the business objects 2900. As shown, aninnermost layer or kernel 2901 of the business object may represent thebusiness object's inherent data. Inherent data may include, for example,an employee's name, age, status, position, address, etc. A second layer2902 may be considered the business object's logic. Thus, the layer 2902includes the rules for consistently embedding the business object in asystem environment as well as constraints defining values and domainsapplicable to the business object. For example, one such constraint maylimit sale of an item only to a customer with whom a company has abusiness relationship. A third layer 2903 includes validation optionsfor accessing the business object. For example, the third layer 2903defines the business object's interface that may be interfaced by otherbusiness objects or applications. A fourth layer 2904 is the accesslayer that defines technologies that may externally access the businessobject.

Accordingly, the third layer 2903 separates the inherent data of thefirst layer 2901 and the technologies used to access the inherent data.As a result of the described structure, the business object reveals onlyan interface that includes a set of clearly defined methods. Thus,applications access the business object via those defined methods. Anapplication wanting access to the business object and the dataassociated therewith usually includes the information or data to executethe clearly defined methods of the business object's interface. Suchclearly defined methods of the business object's interface represent thebusiness object's behavior. That is, when the methods are executed, themethods may change the business object's data. Therefore, an applicationmay utilize any business object by providing the information or datawithout having any concern for the details related to the internaloperation of the business object. Returning to method 2800, a serviceprovider class and data dictionary elements are generated within adevelopment environment at step 2803. In step 2804, the service providerclass is implemented within the development environment.

FIG. 30 illustrates an example method 3000 for a process agentframework. For example, the process agent framework may be the basicinfrastructure to integrate business processes located in differentdeployment units. It may support a loose coupling of these processes bymessage based integration. A process agent may encapsulate the processintegration logic and separate it from business logic of businessobjects. As shown in FIG. 30, an integration scenario and a processcomponent interaction model are defined during a process modeling phasein step 3001. In step 3002, required interface operations and processagents are identified during the process modeling phase also. Next, instep 3003, a service interface, service interface operations, and therelated process agent are created within an enterprise servicesrepository as defined in the process modeling phase. In step 3004, aproxy class for the service interface is generated. Next, in step 3005,a process agent class is created and the process agent is registered. Instep 3006, the agent class is implemented within a developmentenvironment.

FIG. 31 illustrates an example method 3100 for status and actionmanagement (S&AM). For example, status and action management maydescribe the life cycle of a business object (node) by defining actionsand statuses (as their result) of the business object (node), as wellas, the constraints that the statuses put on the actions. In step 3101,the status and action management schemas are modeled per a relevantbusiness object node within an enterprise services repository. In step3102, existing statuses and actions from the business object model areused or new statuses and actions are created. Next, in step 3103, theschemas are simulated to verify correctness and completeness. In step3104, missing actions, statuses, and derivations are created in thebusiness object model with the enterprise services repository.Continuing with method 3100, the statuses are related to correspondingelements in the node in step 3105. In step 3106, status code GDT's aregenerated, including constants and code list providers. Next, in step3107, a proxy class for a business object service provider is generatedand the proxy class S&AM schemas are imported. In step 3108, the serviceprovider is implemented and the status and action management runtimeinterface is called from the actions.

Regardless of the particular hardware or software architecture used, thedisclosed systems or software are generally capable of implementingbusiness objects and deriving (or otherwise utilizing) consistentinterfaces that are suitable for use across industries, acrossbusinesses, and across different departments within a business inaccordance with some or all of the following description. In short,system 100 contemplates using any appropriate combination andarrangement of logical elements to implement some or all of thedescribed functionality.

Moreover, the preceding flowcharts and accompanying descriptionillustrate example methods. The present services environmentcontemplates using or implementing any suitable technique for performingthese and other tasks. It will be understood that these methods are forillustration purposes only and that the described or similar techniquesmay be performed at any appropriate time, including concurrently,individually, or in combination. In addition, many of the steps in theseflowcharts may take place simultaneously and/or in different orders thanas shown. Moreover, the services environment may use methods withadditional steps, fewer steps, and/or different steps, so long as themethods remain appropriate.

Tax Assessment Interfaces

A tax assessment notice is a notice of a tax authority to a taxpayerwhich states that the taxpayer owes taxes or has a refund. TheTaxAssessmentNotice interface performs aTaxAssessmentNoticeERPByBusinessPartnerQueryResponse_In operation. TheTaxAssessmentNoticeERPByBusinessPartnerQueryResponse_In operation canfind one or more tax assessment notices by business partners. TheTaxAssessmentNoticeERPByBusinessPartnerQueryResponse_In operationincludes various message types, namely aTaxAssessmentNoticeERPByBusinessPartnerQuery_sync and aTaxAssessmentNoticeERPByBusinessPartnerResponse_sync. The structure ofthe TaxAssessmentNoticeERPByBusinessPartnerQuery_sync message type isspecified by a TaxAssessmentNoticeERPByBusinessPartnerQueryMessage_syncmessage data type. The structure of theTaxAssessmentNoticeERPByBusinessPartnerResponse_sync message type isspecified by aTaxAssessmentNoticeERPByBusinessPartnerResponseMessage_sync message datatype.

The message choreography of FIG. 32 describes a possible logicalsequence of messages that can be used to realize a Tax Assessment Noticebusiness scenario. A “Requester” system 32000 can query tax assessmentnotice information (e.g., ERP information by business partner) from a“Tax Obligation Processing” system 32002, using aTaxAssesmentNoticeERPByBusinessPartnerQuery_sync message 32004 as shown,for example, in FIG. 32. The “Tax Obligation Processing” system 32002can respond to the query using aTaxAssesmentNoticeERPByBusinessPartnerResponse_sync 32006 as shown, forexample, in FIG. 32.

FIGS. 33-1 through 33-2 illustrate one example logical configuration ofTaxAssessmentNoticeERPMessage_Sync 33000 element structure.Specifically, this figure depicts the arrangement and hierarchy ofvarious components such as one or more levels of packages, entities, anddatatypes, shown here as 33000 through 33052. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxAssessmentNoticeERPMessage_Sync elementstructure 33000 includes, among other things, a MessageHeader 33006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIG. 34 illustrates one example logical configuration ofTaxAssessmentNoticeERPByBusinessPartnerQueryMessage_Sync elementstructure 34000. Specifically, this figure depicts the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 34000 through 34028. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example,TaxAssessmentNoticeERPByBusinessPartnerQueryMessage_Sync elementstructure 34000 includes, among other things, MessageHeader 34006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIGS. 35-1 through 35-2 illustrate one example logicalconfiguration ofTaxAssessmentNoticeERPByBusinessPartnerResponseMessage_Sync elementstructure 35000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 35000 through 35048. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example,TaxAssessmentNoticeERPByBusinessPartnerResponseMessage_Sync elementstructure 35000 includes, among other things, TaxAssessmentNotice 35006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

In further detail, FIGS. 33-1 through 33-2 show an example configurationof an Element Structure that includes aTaxAssessmentNoticeERPMessage_sync 33000 package. TheTaxAssessmentNoticeERPMessage_sync 33000 package is a TxAssmtNtcERPMsg33004 data type. The TaxAssessmentNoticeERPMessage_sync 33000 packageincludes a TaxAssessmentNoticeERPMessage_sync 33002 entity. TheTaxAssessmentNoticeERPMessage_sync 33000 package includes variouspackages, namely a MessageHeader 33006, a TaxAssessmentNotice 33012 anda Log 33048.

The MessageHeader 33006 package is a BasicBusinessDocumentMessageHeader33010 data type. The MessageHeader 33006 package includes aMessageHeader 33008 entity.

The TaxAssessmentNotice 33012 package includes a TaxAssessmentNotice33014 entity. The TaxAssessmentNotice 33012 package includes aContractAccountlnvoiceRequestAssignment 33040 package. TheTaxAssessmentNotice 33014 entity includes various attributes, namely aTaxPayerPartyID 33016, a BillingPeriodID 33020, a LevyTypeCode 33024, aBinaryObject 33028, a BillingPeriodName 33032 and a LevyTypeName 33036.The TaxPayerPartyID 33016 attribute is a PartyInternalID 33018 datatype. The BillingPeriodID 33020 attribute is a BillingPeriodID 33022data type.

The LevyTypeCode 33024 attribute is a LevyTypeCode 33026 data type. Thecode can be a character string of letters, numbers, special characters(possibly with the exception of escape sequences), and symbols. The coderepresents a definitive value, a method, or a property description in anabbreviated or language-independent form.

The BinaryObject 33028 attribute is a BinaryObject 33030 data type. ABinaryObject is a finite data stream of any number of characters inbinary notation (octets). The BinaryObject can be delivered to a partnerusing an implicit representation as an element value, or as a MIME(Multipurpose Internet Mail Extensions) attachment within a message,with a unique URI (Uniform Resource Identifier)-based reference to thecorresponding attachment. The BillingPeriodName 33032 attribute is aMEDIUM_Name 33034 data type. The LevyTypeName 33036 attribute is aMEDIUM_Name 33038 data type.

The ContractAccountlnvoiceRequestAssignment 33040 package includes aContractAccountlnvoiceRequestAssignment 33042 entity. TheContractAccountlnvoiceRequestAssignment 33042 entity includes an ID33044 attribute. The ID 33044 attribute is a Numeric 33046 data type.

The Log 33048 package is a Log 33052 data type. The Log 33048 packageincludes a Log 33050 entity.

In further detail, FIG. 34 illustrates an example configuration of anElement Structure that includes aTaxAssessmentNoticeERPByBusinessPartnerQueryMessage_sync 34000 package.The TaxAssessmentNoticeERPByBusinessPartnerQueryMessage_sync 34000package includes aTaxAssessmentNoticeERPByBusinessPartnerQueryMessage_sync 34002 entity.The TaxAssessmentNoticeERPByBusinessPartnerQueryMessage_sync 34000package includes various packages, namely a MessageHeader 34006 and aSelection 34012.

The MessageHeader 34006 package includes a MessageHeader 34008 entity.The MessageHeader 34008 entity has a cardinality of 1 34010 meaning thatfor each instance of the MessageHeader 34006 package there is oneMessageHeader 34008 entity.

The Selection 34012 package includes aTaxAssessmentNoticeSelectionByBusinessPartner 34014 entity. TheTaxAssessmentNoticeSelectionByBusinessPartner 34014 entity has acardinality of 1 34016 meaning that for each instance of the Selection34012 package there is one TaxAssessmentNoticeSelectionByBusinessPartner34014 entity. The TaxAssessmentNoticeSelectionByBusinessPartner 34014entity includes various attributes, namely a TaxPayerPartyID 34018, aBillingPeriodID 34022 and a LevyTypeCode 34026. The TaxPayerPartyID34018 attribute has a cardinality of 1 34020 meaning that for eachinstance of the TaxAssessmentNoticeSelectionByBusinessPartner 34014entity there is one TaxPayerPartyID 34018 attribute. The BillingPeriodID34022 attribute has a cardinality of 1 34024 meaning that for eachinstance of the TaxAssessmentNoticeSelectionByBusinessPartner 34014entity there is one BillingPeriodID 34022 attribute. The LevyTypeCode34026 attribute has a cardinality of 1 34028 meaning that for eachinstance of the TaxAssessmentNoticeSelectionByBusinessPartner 34014entity there is one LevyTypeCode 34026 attribute. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 33.

In further detail, FIGS. 35-1 through 35-2 illustrate an exampleconfiguration of an Element Structure that includes aTaxAssessmentNoticeERPByBusinessPartnerMessage_sync 35000 package. TheTaxAssessmentNoticeERPByBusinessPartnerMessage_sync 35000 packageincludes a TaxAssessmentNoticeERPByBusinessPartnerMessage_sync 35002entity.

The TaxAssessmentNoticeERPByBusinessPartnerMessage_sync 35000 packageincludes various packages, namely a TaxAssessmentNotice 35004 and a Log35044.

The TaxAssessmentNotice 35004 package includes a TaxAssessmentNotice35006 entity. The TaxAssessmentNotice 35004 package includes aContractAccountlnvoiceRequestAssignment 35034 package. TheTaxAssessmentNotice 35006 entity has a cardinality of 0 . . . 1 35008meaning that for each instance of the TaxAssessmentNotice 35004 packagethere may be one TaxAssessmentNotice 35006 entity. TheTaxAssessmentNotice 35006 entity includes various attributes, namely aTaxPayerPartyID 35010, a BillingPeriodID 35014, a LevyTypeCode 35018, aBinaryObject 35022, a BillingPeriodName 35026 and a LevyTypeName 35030.The TaxPayerPartyID 35010 attribute has a cardinality of 1 35012 meaningthat for each instance of the TaxAssessmentNotice 35006 entity there isone TaxPayerPartyID 35010 attribute. The BillingPeriodID 35014 attributehas a cardinality of 1 35016 meaning that for each instance of theTaxAssessmentNotice 35006 entity there is one BillingPeriodID 35014attribute. The LevyTypeCode 35018 attribute has a cardinality of 1 35020meaning that for each instance of the TaxAssessmentNotice 35006 entitythere is one LevyTypeCode 35018 attribute. The BinaryObject 35022attribute has a cardinality of 1 35024 meaning that for each instance ofthe TaxAssessmentNotice 35006 entity there is one BinaryObject 35022attribute. The BillingPeriodName 35026 attribute has a cardinality of 0. . . 1 35028 meaning that for each instance of the TaxAssessmentNotice35006 entity there may be one BillingPeriodName 35026 attribute. TheLevyTypeName 35030 attribute has a cardinality of 0 . . . 1 35032meaning that for each instance of the TaxAssessmentNotice 35006 entitythere may be one LevyTypeName 35030 attribute.

The ContractAccountlnvoiceRequestAssignment 35034 package includes aContractAccountlnvoiceRequestAssignment 35036 entity. TheContractAccountlnvoiceRequestAssignment 35036 entity has a cardinalityof 0 . . . 1 35038 meaning that for each instance of theContractAccountlnvoiceRequestAssignment 35034 package there may be oneContractAccountlnvoiceRequestAssignment 35036 entity. TheContractAccountlnvoiceRequestAssignment 35036 entity includes aBillingDocumentNumber 35040 attribute. The BillingDocumentNumber 35040attribute has a cardinality of 1 35042 meaning that for each instance ofthe ContractAccountlnvoiceRequestAssignment 35036 entity there is oneBillingDocumentNumber 35040 attribute.

The Log 35044 package includes a Log 35046 entity. The Log 35046 entityhas a cardinality of 1 35048 meaning that for each instance of the Log35044 package there is one Log 35046 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 33.

TaxForm Interfaces

A tax form is a form that may be filed by the taxpayer or the taxpayer'srepresentative. A tax return or tax registration may include one or moretax forms. The TaxForm interface performs various operations, namely aTaxFormERPByLevyTypeQueryResponse_In and aTaxFormERPByIDQueryResponse_In. The TaxFormERPByLevyTypeQueryResponse_Inoperation includes various message types, namely aTaxFormERPByLevyTypeQuery_sync and a TaxFormERPByLevyTypeResponse_sync.The structure of the TaxFormERPByLevyTypeQuery_sync message type isspecified by a TaxFormERPByLevyTypeQueryMessage_sync message data type.The structure of the TaxFormERPByLevyTypeResponse_sync message type isspecified by a TaxFormERPByLevyTypeResponseMessage_sync messagedatatype. The TaxFormERPByIDQueryResponse_In operation includes variousmessage types, namely a TaxFormERPByIDQuery_sync and aTaxFormERPByIDResponse_sync. The structure of theTaxFormERPByIDQuery_sync message type is specified by aTaxFormERPByIDQueryMessage_sync message data type. The structure of theTaxFormERPByIDResponse_sync message type is specified by aTaxFormERPByIDResponseMessage_sync message data type.

FIGS. 36-1 through 36-4 illustrate one example logical configuration ofTaxFormERPMessage_Sync element structure 36000. Specifically, thesefigures depict the arrangement and hierarchy of various components suchas one or more levels of packages, entities, and datatypes, shown hereas 36000 through 36092. As described above, packages may be used torepresent hierarchy levels. Entities are discrete business elements thatare used during a business transaction. Data types are used to typeobject entities and interfaces with a structure. For example,TaxFormERPMessage_Sync message 36000 includes, among other things,MessageHeader 36006. Accordingly, heterogeneous applications maycommunicate using this consistent message configured as such.

Additionally, FIG. 37 illustrates one example logical configuration ofTaxFormERPByLevyTypeQueryMessage_Sync element structure 37000.Specifically, this figure depicts the arrangement and hierarchy ofvarious components such as one or more levels of packages, entities, anddatatypes, shown here as 37000 through 37026. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxFormERPByLevyTypeQueryMessage_Sync message37000 includes, among other things, MessageHeader 37006. Accordingly,heterogeneous applications may communicate using this consistent messageconfigured as such.

Additionally, FIGS. 38-1 through 38-4 illustrate one example logicalconfiguration of TaxFormERPByLevyTypeResponseMessage_Sync elementstructure 38000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 38000 through 38094. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxFormERPByLevyTypeResponseMessage_Sync message38000 includes, among other things, TaxForm 38006. Accordingly,heterogeneous applications may communicate using this consistent messageconfigured as such.

Additionally, FIG. 39 illustrates one example logical configuration ofTaxFormERPByIDQueryMessage_Sync element structure 39000. Specifically,this figure depicts the arrangement and hierarchy of various componentssuch as one or more levels of packages, entities, and datatypes, shownhere as 39000 through 39018. As described above, packages may be used torepresent hierarchy levels. Entities are discrete business elements thatare used during a business transaction. Data types are used to typeobject entities and interfaces with a structure. For example,TaxFormERPByIDQueryMessage_Sync message 39000 includes, among otherthings, MessageHeader 39006. Accordingly, heterogeneous applications maycommunicate using this consistent message configured as such.

Additionally, FIGS. 40-1 through 40-4 illustrate one example logicalconfiguration of TaxFormERPByIDResponseMessage_Sync element structure40000. Specifically, these figures depict the arrangement and hierarchyof various components such as one or more levels of packages, entities,and datatypes, shown here as 40000 through 40098. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxFormERPByIDResponseMessage_Sync message 40000includes, among other things, TaxForm 40006. Accordingly, heterogeneousapplications may communicate using this consistent message configured assuch.

In further detail, FIGS. 36-1 through 36-4 illustrate an exampleconfiguration of an Element Structure that includes aTaxFormERPMessage_Sync 36000 package. The TaxFormERPMessage_Sync 36000package includes a TaxFormERPMessage_Sync 36002 entity. TheTaxFormERPMessage_Sync 36000 package includes various packages, namely aMessageHeader 36004, a TaxForm 36010 and a Log 36088.

The MessageHeader 36004 package is a BusinessDocumentMessageHeader 36008data type. The MessageHeader 36004 package includes a MessageHeader36006 entity.

A BusinessDocumentMessageHeader includes business information from aperspective of a sender application for the identifying and processingof a business document instance within a technical message (and ifapplicable, with a reference to a previous instance of a businessdocument within a previous technical message). TheBusinessDocumentMessageHeader may also include information about thesender and information about the receiver.

The TaxForm 36010 package includes a TaxForm 36012 entity. The TaxForm36010 package includes various packages, namely a Usagedata 36042 and aPropertyValuation 36080.

The TaxForm 36012 entity includes various attributes, namely an ID36014, a TemplateID 36018, a TypeCode 36022, a ValidFromDate 36026, aValidToDate 36030, a BinaryObject 36034 and a TemplateName 36038. The ID36014 attribute is an Identifier 36016 data type. The TemplateID 36018attribute is an InternalServiceRequestTemplateID 36020 data type. TheTypeCode 36022 attribute is a Code 36024 data type. The ValidFromDate36026 attribute is a Date 36028 data type. The ValidToDate 36030attribute is a Date 36032 data type. The BinaryObject 36034 attribute isa BinaryObject 36036 data type. The TemplateName 36038 attribute is aMEDIUM_Name 36040 data type.

The Usagedata 36042 package includes a Usagedata 36044 entity. TheUsagedata 36044 entity includes various attributes, namely a UsageCode36046, a LevyTypeCode 36050, a CoverFormIndicator 36054, aMinimumNumberValue 36058, a MaximumNumberValue 36062 and a LevyTypeName36066. The Usagedata 36044 entity includes a BillingPeriod 36070subordinate entity. The UsageCode 36046 attribute is a Code 36048 datatype. The LevyTypeCode 36050 attribute is a LevyTypeCode 36052 datatype. The CoverFormIndicator 36054 attribute is an Indicator 36056 datatype. The MinimumNumberValue 36058 attribute is a NumberValue 36060 datatype. The MaximumNumberValue 36062 attribute is a NumberValue 36064 datatype. The LevyTypeName 36066 attribute is a MEDIUM_Name 36068 data type.The BillingPeriod 36070 entity includes various attributes, namely aBillingPeriodID 36072 and a BillingPeriodName 36076. The BillingPeriodID36072 attribute is a BillingPeriodID 36074 data type. TheBillingPeriodName 36076 attribute is a MEDIUM_Name 36078 data type. ThePropertyValuation 36080 package includes a PropertyValuation 36082entity. The PropertyValuation 36082 entity includes a PropertyValuation36084 attribute. The PropertyValuation 36084 attribute is aPropertyValuation 36086 data type.

The Log 36088 package is a Log 36092 data type. The Log 36088 packageincludes a Log 36090 entity.

In further detail, FIG. 37 illustrates an example configuration of anElement Structure that includes a TaxFormERPByLevyTypeQueryMessage_sync37000 package. The TaxFormERPByLevyTypeQueryMessage_sync 37000 packageincludes a TaxFormERPByLevyTypeQueryMessage_sync 37002 entity. TheTaxFormERPByLevyTypeQueryMessage_sync 37000 package includes variouspackages, namely a MessageHeader 37004 and a Selection 37010.

The MessageHeader 37004 package includes a MessageHeader 37006 entity.The MessageHeader 37006 entity has a cardinality of 0 . . . 1 37008meaning that for each instance of the MessageHeader 37004 package theremay be one MessageHeader 37006 entity.

The Selection 37010 package includes a TaxFormSelectionByLevyType 37012entity. The TaxFormSelectionByLevyType 37012 entity has a cardinality of1 37014 meaning that for each instance of the Selection 37010 packagethere is one TaxFormSelectionByLevyType 37012 entity. TheTaxFormSelectionByLevyType 37012 entity includes various attributes,namely a LevyTypeCode 37016, a BillingPeriodID 37020 and aTaxFormUsageCode 37024. The LevyTypeCode 37016 attribute has acardinality of 1 37018 meaning that for each instance of theTaxFormSelectionByLevyType 37012 entity there is one LevyTypeCode 37016attribute. The BillingPeriodID 37020 attribute has a cardinality of 0 .. . 1 37022 meaning that for each instance of theTaxFormSelectionByLevyType 37012 entity there may be one BillingPeriodID37020 attribute. The TaxFormUsageCode 37024 attribute has a cardinalityof 1 37026 meaning that for each instance of theTaxFormSelectionByLevyType 37012 entity there is one TaxFormUsageCode37024 attribute. The data types of the various packages, entities, andattributes are described with respect to FIG. 36.

In further detail, FIGS. 38-1 through 38-4 illustrate an exampleconfiguration of an Element Structure that includes aTaxFormERPByLevyTypeResponseMessage_Sync 38000 package. TheTaxFormERPByLevyTypeResponseMessage_Sync 38000 package includes aTaxFormERPByLevyTypeResponseMessage_Sync 38002 entity. TheTaxFormERPByLevyTypeResponseMessage_Sync 38000 package includes variouspackages, namely a TaxForm 38004 and a Log 38090.

The TaxForm 38004 package includes a TaxForm 38006 entity. The TaxForm38004 package includes various packages, namely a UsageData 38038 and aPropertyValuation 38080. The TaxForm 38006 entity has a cardinality of 0. . . n 38008 meaning that for each instance of the TaxForm 38004package there may be one or more TaxForm 38006 entities. The TaxForm38006 entity includes various attributes, namely an ID 38010, aTemplateID 38014, a TypeCode 38018, a ValidFromDate 38022, a ValidToDate38026, a BinaryObject 38030 and a TemplateName 38034. The ID 38010attribute has a cardinality of 1 38012 meaning that for each instance ofthe TaxForm 38006 entity there is one ID 38010 attribute. The TemplateID38014 attribute has a cardinality of 1 38016 meaning that for eachinstance of the TaxForm 38006 entity there is one TemplateID 38014attribute. The TypeCode 38018 attribute has a cardinality of 0 . . . 138020 meaning that for each instance of the TaxForm 38006 entity theremay be one TypeCode 38018 attribute. The ValidFromDate 38022 attributehas a cardinality of 1 38024 meaning that for each instance of theTaxForm 38006 entity there is one ValidFromDate 38022 attribute. TheValidToDate 38026 attribute has a cardinality of 1 38028 meaning thatfor each instance of the TaxForm 38006 entity there is one ValidToDate38026 attribute. The BinaryObject 38030 attribute has a cardinality of 138032 meaning that for each instance of the TaxForm 38006 entity thereis one BinaryObject 38030 attribute. The TemplateName 38034 attributehas a cardinality of 0 . . . 1 38036 meaning that for each instance ofthe TaxForm 38006 entity there may be one TemplateName 38034 attribute.

The UsageData 38038 package includes a UsageData 38040 entity. TheUsageData 38040 entity has a cardinality of 0 . . . 1 38042 meaning thatfor each instance of the UsageData 38038 package there may be oneUsageData 38040 entity. The UsageData 38040 entity includes variousattributes, namely a UsageCode 38044, a LevyTypeCode 38048, aCoverFormIndicator 38052, a MinimumNumberValue 38056, aMaximumNumberValue 38060 and a LevyTypeName 38064. The UsageData 38040entity includes a BillingPeriod 38068 subordinate entity. The UsageCode38044 attribute has a cardinality of 0 . . . 1 38046 meaning that foreach instance of the UsageData 38040 entity there may be one UsageCode38044 attribute. The LevyTypeCode 38048 attribute has a cardinality of 138050 meaning that for each instance of the UsageData 38040 entity thereis one LevyTypeCode 38048 attribute. The CoverFormIndicator 38052attribute has a cardinality of 1 38054 meaning that for each instance ofthe UsageData 38040 entity there is one CoverFormIndicator 38052attribute. The MinimumNumberValue 38056 attribute has a cardinality of 0. . . 1 38058 meaning that for each instance of the UsageData 38040entity there may be one MinimumNumberValue 38056 attribute. TheMaximumNumberValue 38060 attribute has a cardinality of 0 . . . 1 38062meaning that for each instance of the UsageData 38040 entity there maybe one MaximumNumberValue 38060 attribute. The LevyTypeName 38064attribute has a cardinality of 0 . . . 1 38066 meaning that for eachinstance of the UsageData 38040 entity there may be one LevyTypeName38064 attribute.

The BillingPeriod 38068 entity has a cardinality of 0 . . . n 38070meaning that for each instance of the UsageData 38040 entity there maybe one or more BillingPeriod 38068 entities. The BillingPeriod 38068entity includes various attributes, namely a BillingPeriodID 38072 and aBillingPeriodName 38076. The BillingPeriodID 38072 attribute has acardinality of 1 38074 meaning that for each instance of theBillingPeriod 38068 entity there is one BillingPeriodID 38072 attribute.The BillingPeriodName 38076 attribute has a cardinality of 0 . . . 138078 meaning that for each instance of the BillingPeriod 38068 entitythere may be one BillingPeriodName 38076 attribute.

The PropertyValuation 38080 package includes a PropertyValuation 38082entity. The PropertyValuation 38082 entity has a cardinality of 0 . . .1 38084 meaning that for each instance of the PropertyValuation 38080package there may be one PropertyValuation 38082 entity. ThePropertyValuation 38082 entity includes a PropertyValuation 38086attribute. The PropertyValuation 38086 attribute has a cardinality of 1. . . n 38088 meaning that for each instance of the PropertyValuation38082 entity there are one or more PropertyValuation 38086 attributes.

The Log 38090 package includes a Log 38092 entity. The Log 38092 entityhas a cardinality of 1 38094 meaning that for each instance of the Log38090 package there is one Log 38092 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 36.

In further detail, FIG. 39 illustrates an example configuration of anElement Structure that includes a TaxFormERPByIDQueryMessage_sync 39000package. The TaxFormERPByIDQueryMessage_sync 39000 package includes aTaxFormERPByIDQueryMessage_sync 39002 entity. TheTaxFormERPByIDQueryMessage_sync 39000 package includes various packages,namely a MessageHeader 39004 and a Selection 39010.

The MessageHeader 39004 package includes a MessageHeader 39006 entity.The MessageHeader 39006 entity has a cardinality of 0 . . . 1 39008meaning that for each instance of the MessageHeader 39004 package theremay be one MessageHeader 39006 entity.

The Selection 39010 package includes a TaxFormSelectionByID 39012entity. The TaxFormSelectionByID 39012 entity has a cardinality of 139014 meaning that for each instance of the Selection 39010 packagethere is one TaxFormSelectionByID 39012 entity. The TaxFormSelectionByID39012 entity includes an ID 39016 attribute. The ID 39016 attribute hasa cardinality of 1 39018 meaning that for each instance of theTaxFormSelectionByID 39012 entity there is one ID 39016 attribute. Thedata types of the various packages, entities, and attributes aredescribed with respect to FIG. 36.

In further detail, FIGS. 40-1 through 40-4 illustrate an exampleconfiguration of an Element Structure that includes aTaxFormERPByIDResponseMessage_Sync 40000 package.

The TaxFormERPByIDResponseMessage_Sync 40000 package includes aTaxFormERPByIDResponseMessage_Sync 40002 entity. TheTaxFormERPByIDResponseMessage_Sync 40000 package includes variouspackages, namely a TaxForm 40004 and a Log 40094.

The TaxForm 40004 package includes a TaxForm 40006 entity. The TaxForm40004 package includes various packages, namely a UsageData 40042 and aPropertyValuation 40084. The TaxForm 40006 entity has a cardinality of 0. . . 1 40008 meaning that for each instance of the TaxForm 40004package there may be one TaxForm 40006 entity. The TaxForm 40006 entityincludes various attributes, namely an ID 40010, a TemplateID 40014, aTypeCode 40018, a ValidFromDate 40022, a ValidToDate 40026, aBinaryObject 40030, a TemplateName 40034 and a TypeName 40038. The ID40010 attribute has a cardinality of 1 40012 meaning that for eachinstance of the TaxForm 40006 entity there is one ID 40010 attribute.The TemplateID 40014 attribute has a cardinality of 1 40016 meaning thatfor each instance of the TaxForm 40006 entity there is one TemplateID40014 attribute. The TypeCode 40018 attribute has a cardinality of 0 . .. 1 40020 meaning that for each instance of the TaxForm 40006 entitythere may be one TypeCode 40018 attribute. The ValidFromDate 40022attribute has a cardinality of 1 40024 meaning that for each instance ofthe TaxForm 40006 entity there is one ValidFromDate 40022 attribute. TheValidToDate 40026 attribute has a cardinality of 1 40028 meaning thatfor each instance of the TaxForm 40006 entity there is one ValidToDate40026 attribute. The BinaryObject 40030 attribute has a cardinality of 140032 meaning that for each instance of the TaxForm 40006 entity thereis one BinaryObject 40030 attribute. The TemplateName 40034 attributehas a cardinality of 0 . . . 1 40036 meaning that for each instance ofthe TaxForm 40006 entity there may be one TemplateName 40034 attribute.The TypeName 40038 attribute has a cardinality of 0 . . . 1 40040meaning that for each instance of the TaxForm 40006 entity there may beone TypeName 40038 attribute.

The UsageData 40042 package includes a UsageData 40044 entity. TheUsageData 40044 entity has a cardinality of 0 . . . n 40046 meaning thatfor each instance of the UsageData 40042 package there may be one ormore UsageData 40044 entities. The UsageData 40044 entity includesvarious attributes, namely a UsageCode 40048, a LevyTypeCode 40052, aCoverFormIndicator 40056, a MinimumNumberValue 40060, aMaximumNumberValue 40064 and a LevyTypeName 40068. The UsageData 40044entity includes a BillingPeriod 40072 subordinate entity. The UsageCode40048 attribute has a cardinality of 0 . . . 1 40050 meaning that foreach instance of the UsageData 40044 entity there may be one UsageCode40048 attribute. The LevyTypeCode 40052 attribute has a cardinality of 140054 meaning that for each instance of the UsageData 40044 entity thereis one LevyTypeCode 40052 attribute. The CoverFormIndicator 40056attribute has a cardinality of 1 40058 meaning that for each instance ofthe UsageData 40044 entity there is one CoverFormIndicator 40056attribute. The MinimumNumberValue 40060 attribute has a cardinality of 0. . . 1 40062 meaning that for each instance of the UsageData 40044entity there may be one MinimumNumberValue 40060 attribute. TheMaximumNumberValue 40064 attribute has a cardinality of 0 . . . 1 40066meaning that for each instance of the UsageData 40044 entity there maybe one MaximumNumberValue 40064 attribute. The LevyTypeName 40068attribute has a cardinality of 0 . . . 1 40070 meaning that for eachinstance of the UsageData 40044 entity there may be one LevyTypeName40068 attribute.

The BillingPeriod 40072 entity has a cardinality of 0 . . . n 40074meaning that for each instance of the UsageData 40044 entity there maybe one or more BillingPeriod 40072 entities. The BillingPeriod 40072entity includes various attributes, namely a BillingPeriodID 40076 and aBillingPeriodName 40080. The BillingPeriodID 40076 attribute has acardinality of 1 40078 meaning that for each instance of theBillingPeriod 40072 entity there is one BillingPeriodID 40076 attribute.The BillingPeriodName 40080 attribute has a cardinality of 0 . . . 140082 meaning that for each instance of the BillingPeriod 40072 entitythere may be one BillingPeriodName 40080 attribute.

The PropertyValuation 40084 package includes a PropertyValuation 40086entity. The PropertyValuation 40086 entity has a cardinality of 0 . . .1 40088 meaning that for each instance of the PropertyValuation 40084package there may be one PropertyValuation 40086 entity. ThePropertyValuation 40086 entity includes a PropertyValuation 40090attribute. The PropertyValuation 40090 attribute has a cardinality of 1. . . n 40092 meaning that for each instance of the PropertyValuation40086 entity there are one or more PropertyValuation 40090 attributes.

The Log 40094 package includes a Log 40096 entity. The Log 40096 entityhas a cardinality of 1 40098 meaning that for each instance of the Log40094 package there is one Log 40096 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 36.

TaxObject Interfaces

A tax object is a subject of a tax assessment. A tax object may includeattributes which are a basis for a tax calculation. The TaxObjectinterface performs various operations, namely aTaxObjectERPByBusinessPartnerQueryResponse_In, aTaxObjectERPByIDQueryResponse_In, aTaxObjectERPCreateRequestConfirmation_In, aTaxObjectERPUpdateRequestConfirmation_In, and aTaxObjectERPCheckQueryResponse_In. TheTaxObjectERPByBusinessPartnerQueryResponse_In operation can find a taxobject by taxpayer.

The TaxObjectERPByBusinessPartnerQueryResponse_In operation includesvarious message types, namely a TaxObjectERPByBusinessPartnerQuery_syncand a TaxObjectERPByBusinessPartnerResponse_sync. The structure of theTaxObjectERPByBusinessPartnerQuery_sync message type is specified by aTaxObjectERPByBusinessPartnerQueryMessage_sync message data type. Thestructure of the TaxObjectERPByBusinessPartnerResponse_sync message typeis specified by a TaxObjectERPByBusinessPartnerResponseMessage_syncmessage data type. The TaxObjectERPByIDQueryResponse_In operation canread a tax object.

The TaxObjectERPByIDQueryResponse_In operation includes various messagetypes, namely a TaxObjectERPByIDQuery_sync and aTaxObjectERPByIdResponse_sync. The structure of theTaxObjectERPByIDQuery_sync message type is specified by aTaxObjectERPByIDQueryMessage_sync message data type. The structure ofthe TaxObjectERPByIdResponse_sync message type is specified by aTaxObjectERPByIdResponseMessage_sync message data type. TheTaxObjectERPCreateRequestConfirmation_In operation can create a new taxobject.

The TaxObjectERPCreateRequestConfirmation_In operation includes variousmessage types, namely a TaxObjectERPCreateRequest_sync and aTaxObjectERPCreateConfirmation_sync. The structure of theTaxObjectERPCreateRequest_sync message type is specified by aTaxObjectERPCreateRequestMessage_sync message data type. The structureof the TaxObjectERPCreateConfirmation_sync message type is specified bya TaxObjectERPCreateConfirmationMessage_sync message data type. TheTaxObjectERPUpdateRequestConfirmation_In operation can update a taxobject.

The TaxObjectERPUpdateRequestConfirmation_In operation includes variousmessage types, namely a TaxObjectERPUpdateRequest_sync and aTaxObjectERPUpdateConfirmation_sync. The structure of theTaxObjectERPUpdateRequest_sync message type is specified by aTaxObjectERPUpdateRequestMessage_sync message data type. The structureof the TaxObjectERPUpdateConfirmation_sync message type is specified bya TaxObjectERPUpdateConfirmationMessage_sync message data type. TheTaxObjectERPCheckQueryResponse_In operation can check if data of a taxobject is consistent and can be created or changed.

The TaxObjectERPCheckQueryResponse_In operation includes various messagetypes, namely a TaxObjectERPCheckQuery_sync and aTaxObjectERPCheckResponse_sync. The structure of theTaxObjectERPCheckQuery_sync message type is specified by aTaxObjectERPCheckQueryMessage_sync message data type. The structure ofthe TaxObjectERPCheckResponse_sync message type is specified by aTaxObjectERPCheckResponseMessage_sync message data type.

The message choreography of FIG. 41 describes a possible logicalsequence of messages that can be used to realize a Tax Object businessscenario. A “Requester” system 41000 can query tax object ERPinformation by business partner from a “Tax Object Processing” system41002, using a TaxObjectERPByBusinessPartnerQueryMessage_sync message41004 as shown, for example, in FIG. 41. The “Tax Object Processing”system 41002 can respond to the query using aTaxObjectERPByBusinessPartnerResponseMessage_sync 41006 as shown, forexample, in FIG. 41.

The “Requester” system 41000 can query tax object ERP information by IDfrom the “Tax Object Processing” system 41002, using aTaxObjectERPByIDQueryMessage_sync message 41008 as shown, for example,in FIG. 41. The “Tax Object Processing” system 41002 can respond to thequery using a TaxObjectERPByIDResponseMessage_sync 41010 as shown, forexample, in FIG. 41.

The “Requester” system 41000 can request creation of tax object ERPinformation by the “Tax Object Processing” system 41002 using aTaxObjectERPCreateRequestMessage_sync message 41012 as shown, forexample, in FIG. 41. The “Tax Object Processing” system 41002 canconfirm the request using a TaxObjectERPCreateConfirmationMessage_sync41014 as shown, for example, in FIG. 41.

The “Requester” system 41000 can request the update of tax object ERPinformation by the “Tax Object Processing” system 41002 using aTaxObjectERPUpdateRequestMessage_sync message 41016 as shown, forexample, in FIG. 41. The “Tax Object Processing” system 41002 canconfirm the request using a TaxObjectERPUpdateConfirmationMessage_sync41018 as shown, for example, in FIG. 41.

The “Requester” system 41000 can query tax object ERP check informationfrom the “Tax Object Processing” system 41002, using aTaxObjectERPCheckQueryMessage_sync message 41020 as shown, for example,in FIG. 41. The “Tax Object Processing” system 41002 can respond to thequery using a TaxObjectERPCheckResponseMessage_sync 41022 as shown, forexample, in FIG. 41.

FIGS. 42-1 through 42-6 illustrate one example logical configuration ofTaxObjectERPMessage_Sync element structure 42000. Specifically, thesefigures depict the arrangement and hierarchy of various components suchas one or more levels of packages, entities, and datatypes, shown hereas 42000 through 42134. As described above, packages may be used torepresent hierarchy levels. Entities are discrete business elements thatare used during a business transaction. Data types are used to typeobject entities and interfaces with a structure. For example,TaxObjectERPMessage_Sync element structure 42000 includes, among otherthings, MessageHeader 42006. Accordingly, heterogeneous applications maycommunicate using this consistent message configured as such.

Additionally, FIGS. 43-1 through 43-2 illustrate one example logicalconfiguration of TaxObjectERPByBusinessPartnerQueryMessage_sync elementstructure 43000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 43000 through 43036. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObjectERPByBusinessPartnerQueryMessage_syncelement structure 43000 includes, among other things, Selection 43004.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIGS. 44-1 through 44-4 illustrate one example logicalconfiguration of TaxObjectERPByBusinessPartnerResponseMessage_syncelement structure 44000. Specifically, these figures depict thearrangement and hierarchy of various components such as one or morelevels of packages, entities, and datatypes, shown here as 44000 through44096. As described above, packages may be used to represent hierarchylevels. Entities are discrete business elements that are used during abusiness transaction. Data types are used to type object entities andinterfaces with a structure. For example,TaxObjectERPByBusinessPartnerResponseMessage_sync element structure44000 includes, among other things, TaxObject 44006. Accordingly,heterogeneous applications may communicate using this consistent messageconfigured as such.

Additionally, FIG. 45 illustrates one example logical configuration ofTaxObjectERPByIdQuery_sync element structure 45000. Specifically, thisfigure depicts the arrangement and hierarchy of various components suchas one or more levels of packages, entities, and datatypes, shown hereas 45000 through 45012. As described above, packages may be used torepresent hierarchy levels. Entities are discrete business elements thatare used during a business transaction. Data types are used to typeobject entities and interfaces with a structure. For example,TaxObjectERPByIdQuery_sync element structure 45000 includes, among otherthings, Selection 45004. Accordingly, heterogeneous applications maycommunicate using this consistent message configured as such.

Additionally, FIGS. 46-1 through 46-3 illustrate one example logicalconfiguration of TaxObjectERPByIdResponse_sync element structure 46000.Specifically, these figures depict the arrangement and hierarchy ofvarious components such as one or more levels of packages, entities, anddatatypes, shown here as 46000 through 46082. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObjectERPByIdResponse_sync element structure46000 includes, among other things, TaxObject 46006. Accordingly,heterogeneous applications may communicate using this consistent messageconfigured as such.

Additionally, FIGS. 47-1 through 47-2 illustrate one example logicalconfiguration of TaxObjectERPCreateRequest_sync element structure 47000.Specifically, these figures depict the arrangement and hierarchy ofvarious components such as one or more levels of packages, entities, anddatatypes, shown here as 47000 through 47050. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObjectERPCreateRequest_sync element structure47000 includes, among other things, MessageHeader 47006. Accordingly,heterogeneous applications may communicate using this consistent messageconfigured as such.

Additionally, FIGS. 48-1 through 48-3 illustrate one example logicalconfiguration of TaxObjectERPCreateConfirmation_sync element structure48000. Specifically, these figures depict the arrangement and hierarchyof various components such as one or more levels of packages, entities,and datatypes, shown here as 48000 through 48084. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObjectERPCreateConfirmation_sync elementstructure 48000 includes, among other things, MessageHeader 48006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIGS. 49-1 through 49-3 illustrate one example logicalconfiguration of TaxObjectERPUpdateRequest_sync element structure 49000.Specifically, these figures depict the arrangement and hierarchy ofvarious components such as one or more levels of packages, entities, anddatatypes, shown here as 49000 through 49072. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObjectERPUpdateRequest_sync element structure49000 includes, among other things, MessageHeader 49006. Accordingly,heterogeneous applications may communicate using this consistent messageconfigured as such.

Additionally, FIGS. 50-1 through 50-3 illustrate one example logicalconfiguration of TaxObjectERPUpdateConfirmation_sync element structure50000. Specifically, these figures depict the arrangement and hierarchyof various components such as one or more levels of packages, entities,and datatypes, shown here as 50000 through 50084. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObjectERPUpdateConfirmation_sync elementstructure 50000 includes, among other things, MessageHeader 50006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIGS. 51-1 through 51-2 illustrate one example logicalconfiguration of TaxObjectERPCheckQuery_sync element structure 51000.Specifically, these figures depict the arrangement and hierarchy ofvarious components such as one or more levels of packages, entities, anddatatypes, shown here as 51000 through 51064. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObjectERPCheckQuery_sync element structure51000 includes, among other things, TaxObject 51006. Accordingly,heterogeneous applications may communicate using this consistent messageconfigured as such.

Additionally, FIGS. 52-1 through 52-3 illustrate one example logicalconfiguration of TaxObjectERPCheckResponse_sync element structure 52000.Specifically, these figures depict the arrangement and hierarchy ofvarious components such as one or more levels of packages, entities, anddatatypes, shown here as 52000 through 52078. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObjectERPCheckResponse_sync element structure52000 includes, among other things, TaxObject 52006. Accordingly,heterogeneous applications may communicate using this consistent messageconfigured as such.

In further detail, FIGS. 42-1 through 42-6 illustrate an exampleconfiguration of an Element Structure that includes aTaxObjectERPMessage_sync 42000 package. The TaxObjectERPMessage_sync42000 package is a TxObjERPMsg 42004 data type. TheTaxObjectERPMessage_sync 42000 package includes aTaxObjectERPMessage_sync 42002 entity. The TaxObjectERPMessage_sync42000 package includes various packages, namely a MessageHeader 42006, aTaxObject 42012, a ProcessingConditions 42120 and a Log 42130.

The MessageHeader 42006 package is a BasicBusinessDocumentMessageHeader42010 data type. The MessageHeader 42006 package includes aMessageHeader 42008 entity.

The TaxObject 42012 package is a TxObj 42016 data type. The TaxObject42012 package includes a TaxObject 42014 entity. The TaxObject 42012package includes various packages, namely a BusinessLicenseAssignment42050, a PropertyGroup 42058, a PropertyValuation 42064, a LocationData42074 and a TaxObligationAssignment 42086.

The TaxObject 42014 entity includes various attributes, namely apropertyGroupListCompleteTransmissionIndicator 42018, ataxObligationAssignmentListCompleteTransmissionIndicator 42022, aTaxObjectID 42026, a ChangeStateID 42030, an ObjectTypeCode 42034, anObjectTypeName 42038, a TaxObjectName 42042 and a SubapplicationCode42046.

The propertyGroupListCompleteTransmissionIndicator 42018 attribute is anIndicator 42020 data type. ThetaxObligationAssignmentListCompleteTransmissionIndicator 42022 attributeis an Indicator 42024 data type. The TaxObjectID 42026 attribute is anIdentifier 42028 data type. The ChangeStateID 42030 attribute is aChangeStateID 42032 data type. The ObjectTypeCode 42034 attribute is aCode 42036 data type. The ObjectTypeName 42038 attribute is aMEDIUM_Name 42040 data type. The TaxObjectName 42042 attribute is aMEDIUM_Name 42044 data type. The SubapplicationCode 42046 attribute is aCode 42048 data type. The BusinessLicenseAssignment 42050 package is aTxObjERPBusLicAssgmt 42054 data type. The BusinessLicenseAssignment42050 package includes a BusinessLicenseAssignment 42052 entity. ThePropertyGroup 42058 package is a TxObjERPProptyGrp 42062 data type. ThePropertyGroup 42058 package includes a PropertyGroup 42060 entity. ThePropertyValuation 42064 package is a TxObjERPProptyValn 42068 data type.The PropertyValuation 42064 package includes a PropertyValuation 42066entity. The PropertyValuation 42066 entity includes a PropertyValuation42070 attribute. The PropertyValuation 42070 attribute is aPropertyValuation 42072 data type. The LocationData 42074 package is aTxObjERPLocData 42078 data type. The LocationData 42074 package includesa LocationData 42076 entity.

The TaxObligationAssignment 42086 package is a TxObjERPTxOblgnAssgmt42090 data type. The TaxObligationAssignment 42086 package includes aTaxObligationAssignment 42088 entity. The TaxObligationAssignment 42088entity includes various attributes, namely an actionCode 42092, aTaxObligationID 42096, a LevyTypeCode 42100, a LevyTypeName 42104, aStartBillingPeriodID 42108, a StartBillingPeriodName 42112 and aTaxPayerPartyID 42116. The actionCode 42092 attribute is an ActionCode42094 data type. The TaxObligationID 42096 attribute is an Identifier42098 data type. The LevyTypeCode 42100 attribute is a LevyTypeCode42102 data type. The LevyTypeName 42104 attribute is a MEDIUM_Name 42106data type. The StartBillingPeriodID 42108 attribute is a BillingPeriodID42110 data type. The StartBillingPeriodName 42112 attribute is aMEDIUM_Name 42114 data type. The TaxPayerPartyID 42116 attribute is aPartyInternalID 42118 data type. The ProcessingConditions 42120 packageis a QueryProcessingConditions 42124 data type. The ProcessingConditions42120 package includes various entities, namely aQueryProcessingConditions 42122 and a ResponseProcessingConditions42126. The Log 42130 package is a Log 42134 data type. The Log 42130package includes a Log 42132 entity.

In further detail, FIGS. 43-1 through 43-2 illustrate an exampleconfiguration of an Element Structure that includes aTaxObjectERPByBusinessPartnerQueryMessage_sync 43000 package. TheTaxObjectERPByBusinessPartnerQueryMessage_sync 43000 package includes aTaxObjectERPByBusinessPartnerQueryMessage_sync 43002 entity. TheTaxObjectERPByBusinessPartnerQueryMessage_sync 43000 package includesvarious packages, namely a Selection 43004 and a ProcessingConditions43026.

The Selection 43004 package includes aTaxObjectSelectionByTaxPayerPartyID 43006 entity. TheTaxObjectSelectionByTaxPayerPartyID 43006 entity has a cardinality of 143008 meaning that for each instance of the Selection 43004 packagethere is one TaxObjectSelectionByTaxPayerPartyID 43006 entity. TheTaxObjectSelectionByTaxPayerPartyID 43006 entity includes variousattributes, namely an InclusionExclusionCode 43010, anIntervalBoundaryTypeCode 43014, a LowerBoundaryTaxPayerPartyID 43018 andan UpperBoundaryTaxPayerPartyID 43022. The InclusionExclusionCode 43010attribute has a cardinality of 0 . . . 1 43012 meaning that for eachinstance of the TaxObjectSelectionByTaxPayerPartyID 43006 entity theremay be one InclusionExclusionCode 43010 attribute. TheIntervalBoundaryTypeCode 43014 attribute has a cardinality of 0 . . . 143016 meaning that for each instance of theTaxObjectSelectionByTaxPayerPartyID 43006 entity there may be oneIntervalBoundaryTypeCode 43014 attribute. TheLowerBoundaryTaxPayerPartyID 43018 attribute has a cardinality of 143020 meaning that for each instance of theTaxObjectSelectionByTaxPayerPartyID 43006 entity there is oneLowerBoundaryTaxPayerPartyID 43018 attribute. TheUpperBoundaryTaxPayerPartyID 43022 attribute has a cardinality of 0 . .. 1 43024 meaning that for each instance of theTaxObjectSelectionByTaxPayerPartyID 43006 entity there may be oneUpperBoundaryTaxPayerPartyID 43022 attribute.

The ProcessingConditions 43026 package includes aQueryProcessingConditions 43028 entity. The QueryProcessingConditions43028 entity includes various attributes, namely aQueryHitsMaximumNumberValue 43030 and an UnlimitedQueryHitsIndicator43034. The QueryHitsMaximumNumberValue 43030 attribute has a cardinalityof 0 . . . 1 43032 meaning that for each instance of theQueryProcessingConditions 43028 entity there may be oneQueryHitsMaximumNumberValue 43030 attribute. TheUnlimitedQueryHitsIndicator 43034 attribute has a cardinality of 1 43036meaning that for each instance of the QueryProcessingConditions 43028entity there is one UnlimitedQueryHitsIndicator 43034 attribute.

In further detail, FIGS. 44-1 through 44-4 illustrate an exampleconfiguration of an Element Structure that includes aTaxObjectERPByBusinessPartnerResponseMessage_sync 44000 package. TheTaxObjectERPByBusinessPartnerResponseMessage_sync 44000 package includesa TaxObjectERPByBusinessPartnerResponseMessage_sync 44002 entity. TheTaxObjectERPByBusinessPartnerResponseMessage_sync 44000 package includesvarious packages, namely a TaxObject 44004, a ProcessingConditions 44078and a Log 44092.

The TaxObject 44004 package includes a TaxObject 44006 entity. TheTaxObject 44004 package includes various packages, namely aBusinessLicenseAssignment 44026, a PropertyGroup 44032, aPropertyValuation 44038 and a TaxObligationAssignment 44048. TheTaxObject 44006 entity has a cardinality of 0 . . . n 44008 meaning thatfor each instance of the TaxObject 44004 package there may be one ormore TaxObject 44006 entities. The TaxObject 44006 entity includesvarious attributes, namely a TaxObjectID 44010, an ObjectTypeCode 44014,an ObjectTypeName 44018 and a TaxObjectName 44022. The TaxObjectID 44010attribute has a cardinality of 1 44012 meaning that for each instance ofthe TaxObject 44006 entity there is one TaxObjectID 44010 attribute. TheObjectTypeCode 44014 attribute has a cardinality of 1 44016 meaning thatfor each instance of the TaxObject 44006 entity there is oneObjectTypeCode 44014 attribute. The ObjectTypeName 44018 attribute has acardinality of 0 . . . 1 44020 meaning that for each instance of theTaxObject 44006 entity there may be one ObjectTypeName 44018 attribute.The TaxObjectName 44022 attribute has a cardinality of 0 . . . 1 44024meaning that for each instance of the TaxObject 44006 entity there maybe one TaxObjectName 44022 attribute.

The BusinessLicenseAssignment 44026 package includes aBusinessLicenseAssignment 44028 entity. The BusinessLicenseAssignment44028 entity has a cardinality of 0 . . . 1 44030 meaning that for eachinstance of the BusinessLicenseAssignment 44026 package there may be oneBusinessLicenseAssignment 44028 entity.

The PropertyGroup 44032 package includes a PropertyGroup 44034 entity.The PropertyGroup 44034 entity has a cardinality of 0 . . . n 44036meaning that for each instance of the PropertyGroup 44032 package theremay be one or more PropertyGroup 44034 entities. The PropertyValuation44038 package includes a PropertyValuation 44040 entity. ThePropertyValuation 44040 entity has a cardinality of 0 . . . 1 44042meaning that for each instance of the PropertyValuation 44038 packagethere may be one PropertyValuation 44040 entity. The PropertyValuation44040 entity includes a PropertyValuation 44044 attribute. ThePropertyValuation 44044 attribute has a cardinality of 0 . . . n 44046meaning that for each instance of the PropertyValuation 44040 entitythere may be one or more PropertyValuation 44044 attributes.

The TaxObligationAssignment 44048 package includes aTaxObligationAssignment 44050 entity. The TaxObligationAssignment 44050entity has a cardinality of 1 . . . n 44052 meaning that for eachinstance of the TaxObligationAssignment 44048 package there are one ormore TaxObligationAssignment 44050 entities. The TaxObligationAssignment44050 entity includes various attributes, namely a TaxObligationID44054, a LevyTypeCode 44058, a LevyTypeName 44062, aStartBillingPeriodID 44066, a StartBillingPeriodName 44070 and aTaxPayerPartyID 44074. The TaxObligationID 44054 attribute has acardinality of 1 44056 meaning that for each instance of theTaxObligationAssignment 44050 entity there is one TaxObligationID 44054attribute. The LevyTypeCode 44058 attribute has a cardinality of 0 . . .1 44060 meaning that for each instance of the TaxObligationAssignment44050 entity there may be one LevyTypeCode 44058 attribute. TheLevyTypeName 44062 attribute has a cardinality of 0 . . . 1 44064meaning that for each instance of the TaxObligationAssignment 44050entity there may be one LevyTypeName 44062 attribute. TheStartBillingPeriodID 44066 attribute has a cardinality of 0 . . . 144068 meaning that for each instance of the TaxObligationAssignment44050 entity there may be one StartBillingPeriodID 44066 attribute. TheStartBillingPeriodName 44070 attribute has a cardinality of 0 . . . 144072 meaning that for each instance of the TaxObligationAssignment44050 entity there may be one StartBillingPeriodName 44070 attribute.The TaxPayerPartyID 44074 attribute has a cardinality of 1 44076 meaningthat for each instance of the TaxObligationAssignment 44050 entity thereis one TaxPayerPartyID 44074 attribute.

The ProcessingConditions 44078 package includes aResponseProcessingConditions 44080 entity. TheResponseProcessingConditions 44080 entity has a cardinality of 1 44082meaning that for each instance of the ProcessingConditions 44078 packagethere is one ResponseProcessingConditions 44080 entity. TheResponseProcessingConditions 44080 entity includes various attributes,namely a ReturnedQueryHitsNumberValue 44084 and aMoreElementsAvailablelndicator 44088. The ReturnedQueryHitsNumberValue44084 attribute has a cardinality of 1 44086 meaning that for eachinstance of the ResponseProcessingConditions 44080 entity there is oneReturnedQueryHitsNumberValue 44084 attribute. TheMoreElementsAvailablelndicator 44088 attribute has a cardinality of 144090 meaning that for each instance of the ResponseProcessingConditions44080 entity there is one MoreElementsAvailablelndicator 44088attribute.

The Log 44092 package includes a Log 44094 entity. The Log 44094 entityhas a cardinality of 1 44096 meaning that for each instance of the Log44092 package there is one Log 44094 entity.

In further detail, FIG. 45 illustrates an example configuration of anElement Structure that includes a TaxObjectERPByIdQueryMessage_sync45000 package. The TaxObjectERPByIdQueryMessage_sync 45000 packageincludes a TaxObjectERPByIdQueryMessage_sync 45002 entity. TheTaxObjectERPByIdQueryMessage_sync 45000 package includes a Selection45004 package.

The Selection 45004 package includes a TaxObjectSelectionById 45006entity. The TaxObjectSelectionById 45006 entity has a cardinality of 145008 meaning that for each instance of the Selection 45004 packagethere is one TaxObjectSelectionById 45006 entity. TheTaxObjectSelectionById 45006 entity includes a TaxObjectID 45010attribute. The TaxObjectID 45010 attribute has a cardinality of 1 45012meaning that for each instance of the TaxObjectSelectionById 45006entity there is one TaxObjectID 45010 attribute.

In further detail, FIGS. 46-1 through 46-3 illustrate an exampleconfiguration of an Element Structure that includes aTaxObjectERPByIdResponseMessage_sync 46000 package.

The TaxObjectERPByIdResponseMessage_sync 46000 package includes aTaxObjectERPByIdResponseMessage_sync 46002 entity. TheTaxObjectERPByIdResponseMessage_sync 46000 package includes variouspackages, namely a TaxObject 46004 and a Log 46078.

The TaxObject 46004 package includes a TaxObject 46006 entity. TheTaxObject 46004 package includes various packages, namely aBusinessLicenseAssignment 46030, a PropertyGroup 46036, aPropertyValuation 46042 and a TaxObligationAssignment 46052.

The TaxObject 46006 entity has a cardinality of 0 . . . 1 46008 meaningthat for each instance of the TaxObject 46004 package there may be oneTaxObject 46006 entity. The TaxObject 46006 entity includes variousattributes, namely a TaxObjectID 46010, a ChangeStateID 46014, anObjectTypeCode 46018, an ObjectTypeName 46022 and a TaxObjectName 46026.The TaxObjectID 46010 attribute has a cardinality of 1 46012 meaningthat for each instance of the TaxObject 46006 entity there is oneTaxObjectID 46010 attribute. The ChangeStateID 46014 attribute has acardinality of 0 . . . 1 46016 meaning that for each instance of theTaxObject 46006 entity there may be one ChangeStateID 46014 attribute.The ObjectTypeCode 46018 attribute has a cardinality of 1 46020 meaningthat for each instance of the TaxObject 46006 entity there is oneObjectTypeCode 46018 attribute. The ObjectTypeName 46022 attribute has acardinality of 0 . . . 1 46024 meaning that for each instance of theTaxObject 46006 entity there may be one ObjectTypeName 46022 attribute.The TaxObjectName 46026 attribute has a cardinality of 0 . . . 1 46028meaning that for each instance of the TaxObject 46006 entity there maybe one TaxObjectName 46026 attribute.

The BusinessLicenseAssignment 46030 package includes aBusinessLicenseAssignment 46032 entity. The BusinessLicenseAssignment46032 entity has a cardinality of 0 . . . 1 46034 meaning that for eachinstance of the BusinessLicenseAssignment 46030 package there may be oneBusinessLicenseAssignment 46032 entity.

The PropertyGroup 46036 package includes a PropertyGroup 46038 entity.The PropertyGroup 46038 entity has a cardinality of 0 . . . n 46040meaning that for each instance of the PropertyGroup 46036 package theremay be one or more PropertyGroup 46038 entities.

The PropertyValuation 46042 package includes a PropertyValuation 46044entity. The PropertyValuation 46044 entity has a cardinality of 0 . . .1 46046 meaning that for each instance of the PropertyValuation 46042package there may be one PropertyValuation 46044 entity. ThePropertyValuation 46044 entity includes a PropertyValuation 46048attribute. The PropertyValuation 46048 attribute has a cardinality of 0. . . n 46050 meaning that for each instance of the PropertyValuation46044 entity there may be one or more PropertyValuation 46048attributes.

The TaxObligationAssignment 46052 package includes aTaxObligationAssignment 46054 entity. The TaxObligationAssignment 46054entity has a cardinality of 1 . . . n 46056 meaning that for eachinstance of the TaxObligationAssignment 46052 package there are one ormore TaxObligationAssignment 46054 entities. The TaxObligationAssignment46054 entity includes various attributes, namely a TaxObligationID46058, a LevyTypeCode 46062, a LevyTypeName 46066, aStartBillingPeriodID 46070 and a StartBillingPeriodName 46074. TheTaxObligationID 46058 attribute has a cardinality of 1 46060 meaningthat for each instance of the TaxObligationAssignment 46054 entity thereis one TaxObligationID 46058 attribute. The LevyTypeCode 46062 attributehas a cardinality of 0 . . . 1 46064 meaning that for each instance ofthe TaxObligationAssignment 46054 entity there may be one LevyTypeCode46062 attribute. The LevyTypeName 46066 attribute has a cardinality of 0. . . 1 46068 meaning that for each instance of theTaxObligationAssignment 46054 entity there may be one LevyTypeName 46066attribute. The StartBillingPeriodID 46070 attribute has a cardinality of0 . . . 1 46072 meaning that for each instance of theTaxObligationAssignment 46054 entity there may be oneStartBillingPeriodID 46070 attribute. The StartBillingPeriodName 46074attribute has a cardinality of 0 . . . 1 46076 meaning that for eachinstance of the TaxObligationAssignment 46054 entity there may be oneStartBillingPeriodName 46074 attribute.

The Log 46078 package includes a Log 46080 entity. The Log 46080 entityhas a cardinality of 1 46082 meaning that for each instance of the Log46078 package there is one Log 46080 entity.

In further detail, FIGS. 47-1 through 47-2 illustrate an exampleconfiguration of an Element Structure that includes aTaxObjectERPCreateRequestMessage_sync 47000 package.

The TaxObjectERPCreateRequestMessage_sync 47000 package includes aTaxObjectERPCreateRequestMessage_sync 47002 entity. TheTaxObjectERPCreateRequestMessage_sync 47000 package includes variouspackages, namely a MessageHeader 47004 and a TaxObject 47010. TheMessageHeader 47004 package includes a MessageHeader 47006 entity. TheMessageHeader 47006 entity has a cardinality of 0 . . . 1 47008 meaningthat for each instance of the MessageHeader 47004 package there may beone MessageHeader 47006 entity.

The TaxObject 47010 package includes a TaxObject 47012 entity. TheTaxObject 47010 package includes various packages, namely aBusinessLicenseAssignment 47020, a PropertyGroup 47026, aPropertyValuation 47032 and a TaxObligationAssignment 47042.

The TaxObject 47012 entity has a cardinality of 1 47014 meaning that foreach instance of the TaxObject 47010 package there is one TaxObject47012 entity. The TaxObject 47012 entity includes a TaxObjectName 47016attribute. The TaxObjectName 47016 attribute has a cardinality of 0 . .. 1 47018 meaning that for each instance of the TaxObject 47012 entitythere may be one TaxObjectName 47016 attribute.

The BusinessLicenseAssignment 47020 package includes aBusinessLicenseAssignment 47022 entity. The BusinessLicenseAssignment47022 entity has a cardinality of 0 . . . 1 47024 meaning that for eachinstance of the BusinessLicenseAssignment 47020 package there may be oneBusinessLicenseAssignment 47022 entity.

The PropertyGroup 47026 package includes a PropertyGroup 47028 entity.The PropertyGroup 47028 entity has a cardinality of 0 . . . n 47030meaning that for each instance of the PropertyGroup 47026 package theremay be one or more PropertyGroup 47028 entities.

The PropertyValuation 47032 package includes a PropertyValuation 47034entity. The PropertyValuation 47034 entity has a cardinality of 0 . . .1 47036 meaning that for each instance of the PropertyValuation 47032package there may be one PropertyValuation 47034 entity. ThePropertyValuation 47034 entity includes a PropertyValuation 47038attribute. The PropertyValuation 47038 attribute has a cardinality of 0. . . n 47040 meaning that for each instance of the PropertyValuation47034 entity there may be one or more PropertyValuation 47038attributes.

The TaxObligationAssignment 47042 package includes aTaxObligationAssignment 47044 entity. The TaxObligationAssignment 47044entity has a cardinality of 1 . . . n 47046 meaning that for eachinstance of the TaxObligationAssignment 47042 package there are one ormore TaxObligationAssignment 47044 entities. The TaxObligationAssignment47044 entity includes a TaxObligationID 47048 attribute. TheTaxObligationID 47048 attribute has a cardinality of 1 47050 meaningthat for each instance of the TaxObligationAssignment 47044 entity thereis one TaxObligationID 47048 attribute.

In further detail, FIGS. 48-1 through 48-3 illustrate an exampleconfiguration of an Element Structure that includes aTaxObjectERPCreateConfirmationMessage_sync 48000 package. TheTaxObjectERPCreateConfirmationMessage_sync 48000 package includes aTaxObjectERPCreateConfirmationMessage_sync 48002 entity. TheTaxObjectERPCreateConfirmationMessage_sync 48000 package includesvarious packages, namely a MessageHeader 48004, a TaxObject 48010 and aLog 48080.

The MessageHeader 48004 package includes a MessageHeader 48006 entity.The MessageHeader 48006 entity has a cardinality of 0 . . . 1 48008meaning that for each instance of the MessageHeader 48004 package theremay be one MessageHeader 48006 entity.

The TaxObject 48010 package includes a TaxObject 48012 entity. TheTaxObject 48010 package includes various packages, namely aBusinessLicenseAssignment 48032, a PropertyGroup 48038, aPropertyValuation 48044 and a TaxObligationAssignment 48054.

The TaxObject 48012 entity has a cardinality of 0 . . . 1 48014 meaningthat for each instance of the TaxObject 48010 package there may be oneTaxObject 48012 entity. The TaxObject 48012 entity includes variousattributes, namely a TaxObjectID 48016, an ObjectTypeCode 48020, anObjectTypeName 48024 and a TaxObjectName 48028. The TaxObjectID 48016attribute has a cardinality of 1 48018 meaning that for each instance ofthe TaxObject 48012 entity there is one TaxObjectID 48016 attribute. TheObjectTypeCode 48020 attribute has a cardinality of 1 48022 meaning thatfor each instance of the TaxObject 48012 entity there is oneObjectTypeCode 48020 attribute. The ObjectTypeName 48024 attribute has acardinality of 0 . . . 1 48026 meaning that for each instance of theTaxObject 48012 entity there may be one ObjectTypeName 48024 attribute.The TaxObjectName 48028 attribute has a cardinality of 0 . . . 1 48030meaning that for each instance of the TaxObject 48012 entity there maybe one TaxObjectName 48028 attribute.

The BusinessLicenseAssignment 48032 package includes aBusinessLicenseAssignment 48034 entity. The BusinessLicenseAssignment48034 entity has a cardinality of 0 . . . 1 48036 meaning that for eachinstance of the BusinessLicenseAssignment 48032 package there may be oneBusinessLicenseAssignment 48034 entity. The PropertyGroup 48038 packageincludes a PropertyGroup 48040 entity. The PropertyGroup 48040 entityhas a cardinality of 0 . . . n 48042 meaning that for each instance ofthe PropertyGroup 48038 package there may be one or more PropertyGroup48040 entities. The PropertyValuation 48044 package includes aPropertyValuation 48046 entity. The PropertyValuation 48046 entity has acardinality of 0 . . . 1 48048 meaning that for each instance of thePropertyValuation 48044 package there may be one PropertyValuation 48046entity. The PropertyValuation 48046 entity includes a PropertyValuation48050 attribute. The PropertyValuation 48050 attribute has a cardinalityof 0 . . . n 48052 meaning that for each instance of thePropertyValuation 48046 entity there may be one or morePropertyValuation 48050 attributes. The TaxObligationAssignment 48054package includes a TaxObligationAssignment 48056 entity.

The TaxObligationAssignment 48056 entity has a cardinality of 1 . . . n48058 meaning that for each instance of the TaxObligationAssignment48054 package there are one or more TaxObligationAssignment 48056entities. The TaxObligationAssignment 48056 entity includes variousattributes, namely a TaxObligationID 48060, a LevyTypeCode 48064, aLevyTypeName 48068, a StartBillingPeriodID 48072 and aStartBillingPeriodName 48076. The TaxObligationID 48060 attribute has acardinality of 1 48062 meaning that for each instance of theTaxObligationAssignment 48056 entity there is one TaxObligationID 48060attribute. The LevyTypeCode 48064 attribute has a cardinality of 0 . . .1 48066 meaning that for each instance of the TaxObligationAssignment48056 entity there may be one LevyTypeCode 48064 attribute. TheLevyTypeName 48068 attribute has a cardinality of 0 . . . 1 48070meaning that for each instance of the TaxObligationAssignment 48056entity there may be one LevyTypeName 48068 attribute. TheStartBillingPeriodID 48072 attribute has a cardinality of 0 . . . 148074 meaning that for each instance of the TaxObligationAssignment48056 entity there may be one StartBillingPeriodID 48072 attribute. TheStartBillingPeriodName 48076 attribute has a cardinality of 0 . . . 148078 meaning that for each instance of the TaxObligationAssignment48056 entity there may be one StartBillingPeriodName 48076 attribute.

The Log 48080 package includes a Log 48082 entity. The Log 48082 entityhas a cardinality of 1 48084 meaning that for each instance of the Log48080 package there is one Log 48082 entity.

In further detail, FIGS. 49-1 through 49-3 illustrate an exampleconfiguration of an Element Structure that includes aTaxObjectERPUpdateRequestMessage_sync 49000 package. TheTaxObjectERPUpdateRequestMessage_sync 49000 package includes aTaxObjectERPUpdateRequestMessage_sync 49002 entity. TheTaxObjectERPUpdateRequestMessage_sync 49000 package includes variouspackages, namely a MessageHeader 49004 and a TaxObject 49010.

The MessageHeader 49004 package includes a MessageHeader 49006 entity.The MessageHeader 49006 entity has a cardinality of 0 . . . 1 49008meaning that for each instance of the MessageHeader 49004 package theremay be one MessageHeader 49006 entity.

The TaxObject 49010 package includes a TaxObject 49012 entity. TheTaxObject 49010 package includes various packages, namely aBusinessLicenseAssignment 49036, a PropertyGroup 49044, aPropertyValuation 49050 and a TaxObligationAssignment 49060.

The TaxObject 49012 entity has a cardinality of 0 . . . 1 49014 meaningthat for each instance of the TaxObject 49010 package there may be oneTaxObject 49012 entity. The TaxObject 49012 entity includes variousattributes, namely a propertyGroupListCompleteTransmissionIndicator49016, a taxObligationAssignmentListCompleteTransmissionIndicator 49020,a TaxObjectID 49024, a ChangeStateID 49028 and a TaxObjectName 49032.The propertyGroupListCompleteTransmissionIndicator 49016 attribute has acardinality of 1 49018 meaning that for each instance of the TaxObject49012 entity there is one propertyGroupListCompleteTransmissionIndicator49016 attribute. ThetaxObligationAssignmentListCompleteTransmissionIndicator 49020 attributehas a cardinality of 1 49022 meaning that for each instance of theTaxObject 49012 entity there is onetaxObligationAssignmentListCompleteTransmissionIndicator 49020attribute. The TaxObjectID 49024 attribute has a cardinality of 1 49026meaning that for each instance of the TaxObject 49012 entity there isone TaxObjectID 49024 attribute. The ChangeStateID 49028 attribute has acardinality of 1 49030 meaning that for each instance of the TaxObject49012 entity there is one ChangeStateID 49028 attribute. TheTaxObjectName 49032 attribute has a cardinality of 0 . . . 1 49034meaning that for each instance of the TaxObject 49012 entity there maybe one TaxObjectName 49032 attribute.

The BusinessLicenseAssignment 49036 package includes aBusinessLicenseAssignment 49038 entity. The BusinessLicenseAssignment49038 entity has a cardinality of 0 . . . 1 49040 meaning that for eachinstance of the BusinessLicenseAssignment 49036 package there may be oneBusinessLicenseAssignment 49038 entity.

The PropertyGroup 49044 package includes a PropertyGroup 49046 entity.The PropertyGroup 49046 entity has a cardinality of 0 . . . n 49048meaning that for each instance of the PropertyGroup 49044 package theremay be one or more PropertyGroup 49046 entities. The PropertyValuation49050 package includes a PropertyValuation 49052 entity. ThePropertyValuation 49052 entity has a cardinality of 0 . . . 1 49054meaning that for each instance of the PropertyValuation 49050 packagethere may be one PropertyValuation 49052 entity. The PropertyValuation49052 entity includes a PropertyValuation 49056 attribute. ThePropertyValuation 49056 attribute has a cardinality of 0 . . . n 49058meaning that for each instance of the PropertyValuation 49052 entitythere may be one or more PropertyValuation 49056 attributes. TheTaxObligationAssignment 49060 package includes a TaxObligationAssignment49062 entity.

The TaxObligationAssignment 49062 entity has a cardinality of 0 . . . n49064 meaning that for each instance of the TaxObligationAssignment49060 package there may be one or more TaxObligationAssignment 49062entities. The TaxObligationAssignment 49062 entity includes variousattributes, namely an actionCode 49066 and a TaxObligationID 49070. TheactionCode 49066 attribute has a cardinality of 1 49068 meaning that foreach instance of the TaxObligationAssignment 49062 entity there is oneactionCode 49066 attribute. The TaxObligationID 49070 attribute has acardinality of 1 49072 meaning that for each instance of theTaxObligationAssignment 49062 entity there is one TaxObligationID 49070attribute.

In further detail, FIGS. 50-1 through 50-3 illustrate an exampleconfiguration of an Element Structure that includes aTaxObjectERPUpdateConfirmationMessage_sync 50000 package. TheTaxObjectERPUpdateConfirmationMessage_sync 50000 package includes aTaxObjectERPUpdateConfirmationMessage_sync 50002 entity. TheTaxObjectERPUpdateConfirmationMessage_sync 50000 package includesvarious packages, namely a MessageHeader 50004, a TaxObject 50010 and aLog 50080.

The MessageHeader 50004 package includes a MessageHeader 50006 entity.The MessageHeader 50006 entity has a cardinality of 0 . . . 1 50008meaning that for each instance of the MessageHeader 50004 package theremay be one MessageHeader 50006 entity.

The TaxObject 50010 package includes a TaxObject 50012 entity. TheTaxObject 50010 package includes various packages, namely aBusinessLicenseAssignment 50032, a PropertyGroup 50038, aPropertyValuation 50044 and a TaxObligationAssignment 50054.

The TaxObject 50012 entity has a cardinality of 0 . . . 1 50014 meaningthat for each instance of the TaxObject 50010 package there may be oneTaxObject 50012 entity. The TaxObject 50012 entity includes variousattributes, namely a TaxObjectID 50016, an ObjectTypeCode 50020, anObjectTypeName 50024 and a TaxObjectName 50028. The TaxObjectID 50016attribute has a cardinality of 1 50018 meaning that for each instance ofthe TaxObject 50012 entity there is one TaxObjectID 50016 attribute. TheObjectTypeCode 50020 attribute has a cardinality of 1 50022 meaning thatfor each instance of the TaxObject 50012 entity there is oneObjectTypeCode 50020 attribute. The ObjectTypeName 50024 attribute has acardinality of 0 . . . 1 50026 meaning that for each instance of theTaxObject 50012 entity there may be one ObjectTypeName 50024 attribute.The TaxObjectName 50028 attribute has a cardinality of 0 . . . 1 50030meaning that for each instance of the TaxObject 50012 entity there maybe one TaxObjectName 50028 attribute.

The BusinessLicenseAssignment 50032 package includes aBusinessLicenseAssignment 50034 entity. The BusinessLicenseAssignment50034 entity has a cardinality of 0 . . . 1 50036 meaning that for eachinstance of the BusinessLicenseAssignment 50032 package there may be oneBusinessLicenseAssignment 50034 entity.

The PropertyGroup 50038 package includes a PropertyGroup 50040 entity.The PropertyGroup 50040 entity has a cardinality of 0 . . . n 50042meaning that for each instance of the PropertyGroup 50038 package theremay be one or more PropertyGroup 50040 entities.

The PropertyValuation 50044 package includes a PropertyValuation 50046entity. The PropertyValuation 50046 entity has a cardinality of 0 . . .1 50048 meaning that for each instance of the PropertyValuation 50044package there may be one PropertyValuation 50046 entity. ThePropertyValuation 50046 entity includes a PropertyValuation 50050attribute. The PropertyValuation 50050 attribute has a cardinality of 0. . . n 50052 meaning that for each instance of the PropertyValuation50046 entity there may be one or more PropertyValuation 50050attributes. The TaxObligationAssignment 50054 package includes aTaxObligationAssignment 50056 entity.

The TaxObligationAssignment 50056 entity has a cardinality of 0 . . . n50058 meaning that for each instance of the TaxObligationAssignment50054 package there may be one or more TaxObligationAssignment 50056entities. The TaxObligationAssignment 50056 entity includes variousattributes, namely a TaxObligationID 50060, a LevyTypCode 50064, aLevyTypName 50068, a StartBillingPeriodID 50072 and aStartBillingPeriodName 50076. The TaxObligationID 50060 attribute has acardinality of 1 50062 meaning that for each instance of theTaxObligationAssignment 50056 entity there is one TaxObligationID 50060attribute. The LevyTypCode 50064 attribute has a cardinality of 0 . . .1 50066 meaning that for each instance of the TaxObligationAssignment50056 entity there may be one LevyTypCode 50064 attribute. TheLevyTypName 50068 attribute has a cardinality of 0 . . . 1 50070 meaningthat for each instance of the TaxObligationAssignment 50056 entity theremay be one LevyTypName 50068 attribute. The StartBillingPeriodID 50072attribute has a cardinality of 0 . . . 1 50074 meaning that for eachinstance of the TaxObligationAssignment 50056 entity there may be oneStartBillingPeriodID 50072 attribute. The StartBillingPeriodName 50076attribute has a cardinality of 0 . . . 1 50078 meaning that for eachinstance of the TaxObligationAssignment 50056 entity there may be oneStartBillingPeriodName 50076 attribute.

The Log 50080 package includes a Log 50082 entity. The Log 50082 entityhas a cardinality of 1 50084 meaning that for each instance of the Log50080 package there is one Log 50082 entity.

In further detail, FIGS. 51-1 through 51-2 illustrate an exampleconfiguration of an Element Structure that includes aTaxObjectERPCheckQueryMessage_sync 51000 package.

The TaxObjectERPCheckQueryMessage_sync 51000 package includes aTaxObjectERPCheckQueryMessage_sync 51002 entity. TheTaxObjectERPCheckQueryMessage_sync 51000 package includes a TaxObject51004 package.

The TaxObject 51004 package includes a TaxObject 51006 entity. TheTaxObject 51004 package includes various packages, namely aBusinessLicenseAssignment 51026, a PropertyGroup 51032, aPropertyValuation 51038 and a TaxObligationAssignment 51048.

The TaxObject 51006 entity has a cardinality of 1 51008 meaning that foreach instance of the TaxObject 51004 package there is one TaxObject51006 entity. The TaxObject 51006 entity includes various attributes,namely a TaxObjectID 51010, a ChangeStateID 51014, an ObjectTypeCode51018 and a TaxObjectName 51022. The TaxObjectID 51010 attribute has acardinality of 1 51012 meaning that for each instance of the TaxObject51006 entity there is one TaxObjectID 51010 attribute. The ChangeStateID51014 attribute has a cardinality of 0 . . . 1 51016 meaning that foreach instance of the TaxObject 51006 entity there may be oneChangeStateID 51014 attribute. The ObjectTypeCode 51018 attribute has acardinality of 1 51020 meaning that for each instance of the TaxObject51006 entity there is one ObjectTypeCode 51018 attribute. TheTaxObjectName 51022 attribute has a cardinality of 0 . . . 1 51024meaning that for each instance of the TaxObject 51006 entity there maybe one TaxObjectName 51022 attribute.

The BusinessLicenseAssignment 51026 package includes aBusinessLicenseAssignment 51028 entity. The BusinessLicenseAssignment51028 entity has a cardinality of 0 . . . 1 51030 meaning that for eachinstance of the BusinessLicenseAssignment 51026 package there may be oneBusinessLicenseAssignment 51028 entity. The PropertyGroup 51032 packageincludes a PropertyGroup 51034 entity. The PropertyGroup 51034 entityhas a cardinality of 0 . . . n 51036 meaning that for each instance ofthe PropertyGroup 51032 package there may be one or more PropertyGroup51034 entities.

The PropertyValuation 51038 package includes a PropertyValuation 51040entity. The PropertyValuation 51040 entity has a cardinality of 0 . . .1 51042 meaning that for each instance of the PropertyValuation 51038package there may be one PropertyValuation 51040 entity. ThePropertyValuation 51040 entity includes a PropertyValuation 51044attribute. The PropertyValuation 51044 attribute has a cardinality of 0. . . n 51046 meaning that for each instance of the PropertyValuation51040 entity there may be one or more PropertyValuation 51044attributes.

The TaxObligationAssignment 51048 package includes aTaxObligationAssignment 51050 entity. The TaxObligationAssignment 51050entity has a cardinality of 0 . . . n 51052 meaning that for eachinstance of the TaxObligationAssignment 51048 package there may be oneor more TaxObligationAssignment 51050 entities. TheTaxObligationAssignment 51050 entity includes various attributes, namelya TaxObligationID 51054, a RevenueTypeCode 51058 and aPeriodAssignmentCode 51062. The TaxObligationID 51054 attribute has acardinality of 1 51056 meaning that for each instance of theTaxObligationAssignment 51050 entity there is one TaxObligationID 51054attribute. The RevenueTypeCode 51058 attribute has a cardinality of 0 .. . 1 51060 meaning that for each instance of theTaxObligationAssignment 51050 entity there may be one RevenueTypeCode51058 attribute. The PeriodAssignmentCode 51062 attribute has acardinality of 0 . . . 1 51064 meaning that for each instance of theTaxObligationAssignment 51050 entity there may be onePeriodAssignmentCode 51062 attribute.

In further detail, FIGS. 52-1 through 52-3 illustrate an exampleconfiguration of an Element Structure that includes aTaxObjectERPCheckResponseMessage_sync 52000 package. TheTaxObjectERPCheckResponseMessage_sync 52000 package includes aTaxObjectERPCheckResponseMessage_sync 52002 entity. TheTaxObjectERPCheckResponseMessage_sync 52000 package includes variouspackages, namely a TaxObject 52004 and a Log 52074.

The TaxObject 52004 package includes a TaxObject 52006 entity. TheTaxObject 52004 package includes various packages, namely aBusinessLicenseAssignment 52026, a PropertyGroup 52032, aPropertyValuation 52038 and a TaxObligationAssignment 52048.

The TaxObject 52006 entity has a cardinality of 0 . . . 1 52008 meaningthat for each instance of the TaxObject 52004 package there may be oneTaxObject 52006 entity. The TaxObject 52006 entity includes variousattributes, namely a TaxObjectID 52010, an ObjectTypeCode 52014, anObjectTypeName 52018 and a TaxObjectName 52022. The TaxObjectID 52010attribute has a cardinality of 1 52012 meaning that for each instance ofthe TaxObject 52006 entity there is one TaxObjectID 52010 attribute. TheObjectTypeCode 52014 attribute has a cardinality of 0 . . . 1 52016meaning that for each instance of the TaxObject 52006 entity there maybe one ObjectTypeCode 52014 attribute. The ObjectTypeName 52018attribute has a cardinality of 0 . . . 1 52020 meaning that for eachinstance of the TaxObject 52006 entity there may be one ObjectTypeName52018 attribute. The TaxObjectName 52022 attribute has a cardinality of0 . . . 1 52024 meaning that for each instance of the TaxObject 52006entity there may be one TaxObjectName 52022 attribute.

The BusinessLicenseAssignment 52026 package includes aBusinessLicenseAssignment 52028 entity. The BusinessLicenseAssignment52028 entity has a cardinality of 0 . . . 1 52030 meaning that for eachinstance of the BusinessLicenseAssignment 52026 package there may be oneBusinessLicenseAssignment 52028 entity.

The PropertyGroup 52032 package includes a PropertyGroup 52034 entity.

The PropertyGroup 52034 entity has a cardinality of 0 . . . n 52036meaning that for each instance of the PropertyGroup 52032 package theremay be one or more PropertyGroup 52034 entities.

The PropertyValuation 52038 package includes a PropertyValuation 52040entity. The PropertyValuation 52040 entity has a cardinality of 0 . . .1 52042 meaning that for each instance of the PropertyValuation 52038package there may be one PropertyValuation 52040 entity. ThePropertyValuation 52040 entity includes a PropertyValuation 52044attribute. The PropertyValuation 52044 attribute has a cardinality of 0. . . n 52046 meaning that for each instance of the PropertyValuation52040 entity there may be one or more PropertyValuation 52044attributes.

The TaxObligationAssignment 52048 package includes aTaxObligationAssignment 52050 entity. The TaxObligationAssignment 52050entity has a cardinality of 0 . . . n 52052 meaning that for eachinstance of the TaxObligationAssignment 52048 package there may be oneor more TaxObligationAssignment 52050 entities. TheTaxObligationAssignment 52050 entity includes various attributes, namelya TaxObligationID 52054, a LevyTypCode 52058, a LevyTypName 52062, aStartBillingPeriodID 52066 and a StartBillingPeriodName 52070. TheTaxObligationID 52054 attribute has a cardinality of 1 52056 meaningthat for each instance of the TaxObligationAssignment 52050 entity thereis one TaxObligationID 52054 attribute. The LevyTypCode 52058 attributehas a cardinality of 0 . . . 1 52060 meaning that for each instance ofthe TaxObligationAssignment 52050 entity there may be one LevyTypCode52058 attribute. The LevyTypName 52062 attribute has a cardinality of 0. . . 1 52064 meaning that for each instance of theTaxObligationAssignment 52050 entity there may be one LevyTypName 52062attribute. The StartBillingPeriodID 52066 attribute has a cardinality of0 . . . 1 52068 meaning that for each instance of theTaxObligationAssignment 52050 entity there may be oneStartBillingPeriodID 52066 attribute. The StartBillingPeriodName 52070attribute has a cardinality of 0 . . . 1 52072 meaning that for eachinstance of the TaxObligationAssignment 52050 entity there may be oneStartBillingPeriodName 52070 attribute.

The Log 52074 package includes a Log 52076 entity. The Log 52076 entityhas a cardinality of 1 52078 meaning that for each instance of the Log52074 package there is one Log 52076 entity.

TaxObligation Interfaces

A tax obligation is a legal requirement that may be fulfilled by ataxpayer. A tax obligation includes the filing of tax returns andpayment of taxes at defined due dates, which may incur a penalty forlack of fulfillment. The TaxObligation interface performs variousoperations, namely a TaxObligationERPChangeRequestConfirmation_In, aTaxObligationERPFilingObligationChangeRequestConfirmation_In, aTaxObligationERPCheckQueryResponse_In, aTaxObligationERPFilingObligationCheckQueryResponse_In, aTaxObligationERPCreateRequestConfirmation_In, aTaxObligationERPByBusinessPartnerQueryResponse_In, aTaxObligationERPLevyTypeByBusinessPartnerQueryResponse_In, aTaxObligationERPRegistrationFormByIdQueryResponse_In, aTaxObligationERPFilingObligationByIdQueryResponse_In, and aTaxObligationERPByIdQueryResponse_In.

The TaxObligationERPChangeRequestConfirmation_In operation can changeregistration information based on tax registration form, and can alsoderegister. The TaxObligationERPChangeRequestConfirmation_In operationincludes various message types, namely aTaxObligationERPChangeRequest_sync and aTaxObligationERPChangeConfirmation_sync. The structure of theTaxObligationERPChangeRequest_sync message type is specified by aTaxObligationERPChangeRequestMessage_sync message data type. Thestructure of the TaxObligationERPChangeConfirmation_sync message type isspecified by a TaxObligationERPChangeConfirmationMessage_sync messagedata type.

The TaxObligationERPFilingObligationChangeRequestConfirmation_Inoperation can maintain a tax filing obligation for a given revenue typeand tax assessment. TheTaxObligationERPFilingObligationChangeRequestConfirmation_In operationincludes various message types, namely aTaxObligationERPFilingObligationChangeRequest_sync and aTaxObligationERPFilingObligationChangeConfirmation_sync. The structureof the TaxObligationERPFilingObligationChangeRequest_sync message typeis specified by aTaxObligationERPFilingObligationChangeRequestMessage_sync message datatype. The structure of theTaxObligationERPFilingObligationChangeConfirmation_sync message type isspecified by aTaxObligationERPFilingObligationChangeConfirmationMessage_sync messagedata type.

The TaxObligationERPCheckQueryResponse_In operation can check if data ofa tax obligation is consistent and can be created or changed. TheTaxObligationERPCheckQueryResponse_In operation includes various messagetypes, namely a TaxObligationERPCheckQuery_sync and aTaxObligationERPCheckResponse_sync. The structure of theTaxObligationERPCheckQuery_sync message type is specified by aTaxObligationERPCheckQueryMessage_sync message data type. The structureof the TaxObligationERPCheckResponse_sync message type is specified by aTaxObligationERPCheckResponseMessage_sync message data type.

The TaxObligationERPFilingObligationCheckQueryResponse_In operation cancheck if tax filing obligation is consistent and can be created orchanged. The TaxObligationERPFilingObligationCheckQueryResponse_Inoperation includes various message types, namely aTaxObligationERPFilingObligationCheckQuery_sync and aTaxObligationERPFilingObligationCheckResponse_sync. The structure of theTaxObligationERPFilingObligationCheckQuery_sync message type isspecified by a TaxObligationERPFilingObligationCheckQueryMessage_syncmessage data type. The structure of theTaxObligationERPFilingObligationCheckResponse_sync message type isspecified by a TaxObligationERPFilingObligationCheckResponseMessage_syncmessage data type.

The TaxObligationERPCreateRequestConfirmation_In operation can createregistration information based on a tax registration form. TheTaxObligationERPCreateRequestConfirmation_In operation includes variousmessage types, namely a TaxObligationERPCreateRequest_sync and aTaxObligationERPCreateConfirmation_sync. The structure of theTaxObligationERPCreateRequest_sync message type is specified by aTaxObligationERPCreateRequestMessage_sync message data type. Thestructure of the TaxObligationERPCreateConfirmation_sync message type isspecified by a TaxObligationERPCreateConfirmationMessage_sync messagedata type.

The TaxObligationERPByBussinessPartnerQueryResponse_In operation canreturn all tax obligations for tax payers. TheTaxObligationERPByBussinessPartnerQueryResponse_In operation includesvarious message types, namely aTaxObligationERPByBussinessPartnerQuery_sync and aTaxObligationERPByBussinessPartnerResponse_sync. The structure of theTaxObligationERPByBussinessPartnerQuery_sync message type is specifiedby a TaxObligationERPByBussinessPartnerQueryMessage_sync message datatype. The structure of theTaxObligationERPByBussinessPartnerResponse_sync message type isspecified by a TaxObligationERPByBussinessPartnerResponseMessage_syncmessage data type.

The TaxObligationERPLevyTypeByBusinessPartnerQueryResponse_In operationcan return all levy types that exist for tax payers. TheTaxObligationERPLevyTypeByBusinessPartnerQueryResponse_In operationincludes various message types, namely aTaxObligationERPLevyTypeByBusinessPartnerQuery_sync and aTaxObligationERPLevyTypeByBusinessPartnerResponse_sync. The structure ofthe TaxObligationERPLevyTypeByBusinessPartnerQuery_sync message type isspecified by aTaxObligationERPLevyTypeByBusinessPartnerQueryMessage_sync message datatype. The structure of theTaxObligationERPLevyTypeByBusinessPartnerResponse_sync message type isspecified by aTaxObligationERPLevyTypeByBusinessPartnerResponseMessage_sync messagedata type.

The TaxObligationERPRegistrationFormByIdQueryResponse_In operation canread tax registration form data. TheTaxObligationERPRegistrationFormByIdQueryResponse_In operation includesvarious message types, namely aTaxObligationERPRegistrationFormByIdQuery_sync and aTaxObligationERPRegistrationFormByIdResponse_sync. The structure of theTaxObligationERPRegistrationFormByIdQuery_sync message type is specifiedby a TaxObligationERPRegistrationFormByIdQueryMessage_sync message datatype. The structure of theTaxObligationERPRegistrationFormByIdResponse_sync message type isspecified by a TaxObligationERPRegistrationFormByIdResponseMessage_syncmessage data type.

The TaxObligationERPFilingObligationByIdQueryResponse_In operation canreturn filing obligations for a tax obligation. TheTaxObligationERPFilingObligationByIdQueryResponse_In operation includesvarious message types, namely aTaxObligationERPFilingObligationByIdQuery_sync and aTaxObligationERPFilingObligationByIdResponse_sync. The structure of theTaxObligationERPFilingObligationByIdQuery_sync message type is specifiedby a TaxObligationERPFilingObligationByIdQueryMessage_sync message datatype. The structure of theTaxObligationERPFilingObligationByIdResponse_sync message type isspecified by a TaxObligationERPFilingObligationByIdResponseMessage_syncmessage data type.

The TaxObligationERPByIdQueryResponse_In operation can return a specifictax obligation. The TaxObligationERPByIdQueryResponse_In operationincludes various message types, namely a TaxObligationERPByIdQuery_syncand a TaxObligationERPByIdResponse_sync. The structure of theTaxObligationERPByIdQuery_sync message type is specified by aTaxObligationERPByIdQueryMessage_sync message data type. The structureof the TaxObligationERPByIdResponse_sync message type is specified by aTaxObligationERPByIdResponseMessage_sync message data type.

The message choreography of FIG. 53 describes a possible logicalsequence of messages that can be used to realize a Tax Obligationbusiness scenario. A “Requester” system 53000 can query tax obligationERP information from a “Tax Processing” system 53002, using aTaxObligationERPChangeRequest_sync message 53004 as shown, for example,in FIG. 53. The “Tax Processing” system 53002 can respond to the queryusing a TaxObligationERPChangeConfirmation_sync 53006 as shown, forexample, in FIG. 53.

The “Requester” system 53000 can request the change of tax obligationERP filing obligation information in the “Tax Processing” system 53002using a TaxObligationERPFilingObligationChangeRequest_sync message 53008as shown, for example, in FIG. 53. The “Tax Processing” system 53002 canconfirm the request using aTaxObligationERPFilingObligationChangeConfirmation_sync 53010 as shown,for example, in FIG. 53.

The “Requester” system 53000 can query a tax obligation ERP check in the“Tax Processing” system 53002 using a TaxObligationERPCheckQuery_syncmessage 53012 as shown, for example, in FIG. 53. The “Tax Processing”system 53002 can confirm the request using aTaxObligationERPCheckResponse_sync 53014 as shown, for example, in FIG.53.

The “Requester” system 53000 can query tax obligation ERP filingobligation check information in the “Tax Processing” system 53002 usinga TaxObligationERPFilingObligationCheckQuery_sync message 53016 asshown, for example, in FIG. 53. The “Tax Processing” system 53002 canrespond to the query using aTaxObligationERPFilingObligationCheckResponse_sync 53018 as shown, forexample, in FIG. 53.

The “Requester” system 53000 can request the creation of tax obligationERP information in the “Tax Processing” system 53002 using aTaxObligationERPCreateRequest_sync message 53020 as shown, for example,in FIG. 53. The “Tax Processing” system 53002 can confirm the requestusing a TaxObligationERPCreateConfirmation_sync 53022 as shown, forexample, in FIG. 53.

The “Requester” system 53000 can query tax obligation ERP information bybusiness partner in the “Tax Processing” system 53002 using aTaxObligationERPByBusinessPartnerQuery_sync message 53024 as shown, forexample, in FIG. 53. The “Tax Processing” system 53002 can respond tothe query using a TaxObligationERPByBusinessPartnerResponse_sync 53026as shown, for example, in FIG. 53.

The “Requester” system 53000 can query tax obligation ERP revenue typeinformation by business partner in the “Tax Processing” system 53002using a TaxObligationERPRevenueTypeByBusinessPartnerQuery_sync message53028 as shown, for example, in FIG. 53. The “Tax Processing” system53002 can respond to the query using aTaxObligationERPRevenueTypeByBusinessPartnerResponse_sync 53030 asshown, for example, in FIG. 53.

The “Requester” system 53000 can query tax obligation ERP registrationform information by ID in the “Tax Processing” system 53002 using aTaxObligationERPRegistrationFormByIDQuery_sync message 53032 as shown,for example, in FIG. 53. The “Tax Processing” system 53002 can respondto the query using a TaxObligationERPRegistrationFormByIDResponse_sync53034 as shown, for example, in FIG. 53.

The “Requester” system 53000 can query tax obligation ERP filinginformation by ID in the “Tax Processing” system 53002 using aTaxObligationERPFilingObligationByIDQuery_sync message 53036 as shown,for example, in FIG. 53. The “Tax Processing” system 53002 can respondto the query using a TaxObligationERPFilingObligationByIDResponse_sync53038 as shown, for example, in FIG. 53.

FIGS. 54-1 through 54-15 illustrate one example logical configuration ofTaxObligationERPMessage_Sync element structure 54000. Specifically,these figures depict the arrangement and hierarchy of various componentssuch as one or more levels of packages, entities, and datatypes, shownhere as 54000 through 54362. As described above, packages may be used torepresent hierarchy levels. Entities are discrete business elements thatare used during a business transaction. Data types are used to typeobject entities and interfaces with a structure. For example,TaxObligationERPMessage_Sync element structure 54000 includes, amongother things, MessageHeader 54006. Accordingly, heterogeneousapplications may communicate using this consistent message configured assuch.

Additionally, FIGS. 55-1 through 55-7 illustrate one example logicalconfiguration of TaxObligationERPChangeRequestMessage_Sync elementstructure 55000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 55000 through 55174. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObligationERPChangeRequestMessage_Syncelement structure 55000 includes, among other things, MessageHeader55006. Accordingly, heterogeneous applications may communicate usingthis consistent message configured as such.

Additionally, FIGS. 56-1 through 56-9 illustrate one example logicalconfiguration of TaxObligationERPChangeConfirmationMessage_Sync elementstructure 56000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 56000 through 56224. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObligationERPChangeConfirmationMessage_Syncelement structure 56000 includes, among other things, MessageHeader56006. Accordingly, heterogeneous applications may communicate usingthis consistent message configured as such.

Additionally, FIGS. 57-1 through 57-3 illustrate one example logicalconfiguration ofTaxObligationERPFilingObligationChangeRequestMessage_Sync elementstructure 57000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 57000 through 57076. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example,TaxObligationERPFilingObligationChangeRequestMessage_Sync elementstructure 57000 includes, among other things, MessageHeader 57006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIGS. 58-1 through 58-5 illustrate one example logicalconfiguration ofTaxObligationERPFilingObligationChangeConfirmationMessage_Sync elementstructure 58000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 58000 through 58126. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example,TaxObligationERPFilingObligationChangeConfirmationMessage_Sync elementstructure 58000 includes, among other things, MessageHeader 58006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIGS. 59-1 through 59-7 illustrate one example logicalconfiguration of TaxObligationERPCheckQueryMessage_Sync elementstructure 59000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 59000 through 59166. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObligationERPCheckQueryMessage_Sync elementstructure 59000 includes, among other things, MessageHeader 59006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIGS. 60-1 through 60-9 illustrate one example logicalconfiguration of TaxObligationERPCheckResponseMessage_Sync elementstructure 60000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 60000 through 60224. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObligationERPCheckResponseMessage_Syncelement structure 60000 includes, among other things, MessageHeader60006. Accordingly, heterogeneous applications may communicate usingthis consistent message configured as such.

Additionally, FIGS. 61-1 through 61-3 illustrate one example logicalconfiguration of TaxObligationERPFilingObligationCheckQueryMessage_Syncelement structure 61000. Specifically, these figures depict thearrangement and hierarchy of various components such as one or morelevels of packages, entities, and datatypes, shown here as 61000 through61068. As described above, packages may be used to represent hierarchylevels. Entities are discrete business elements that are used during abusiness transaction. Data types are used to type object entities andinterfaces with a structure. For example,TaxObligationERPFilingObligationCheckQueryMessage_Sync element structure61000 includes, among other things, MessageHeader 61006. Accordingly,heterogeneous applications may communicate using this consistent messageconfigured as such.

Additionally, FIGS. 62-1 through 62-5 illustrate one example logicalconfiguration ofTaxObligationERPFilingObligationCheckResponseMessage_Sync elementstructure 62000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 62000 through 62126. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example,TaxObligationERPFilingObligationCheckResponseMessage_Sync elementstructure 62000 includes, among other things, MessageHeader 62006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIGS. 63-1 through 63-6 illustrate one example logicalconfiguration of TaxObligationERPCreateRequestMessage_Sync elementstructure 63000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 63000 through 63158. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObligationERPCreateRequestMessage_Syncelement structure 63000 includes, among other things, MessageHeader63006. Accordingly, heterogeneous applications may communicate usingthis consistent message configured as such.

Additionally, FIGS. 64-1 through 64-9 illustrate one example logicalconfiguration of TaxObligationERPCreateConfirmationMessage_Sync elementstructure 64000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 64000 through 64224. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObligationERPCreateConfirmationMessage_Syncelement structure 64000 includes, among other things, MessageHeader64006. Accordingly, heterogeneous applications may communicate usingthis consistent message configured as such.

Additionally, FIGS. 65-1 through 65-2 illustrate one example logicalconfiguration of TaxObligationERPByBusinessPartnerQueryMessage_Syncelement structure 65000. Specifically, these figures depict thearrangement and hierarchy of various components such as one or morelevels of packages, entities, and datatypes, shown here as 65000 through65042. As described above, packages may be used to represent hierarchylevels. Entities are discrete business elements that are used during abusiness transaction. Data types are used to type object entities andinterfaces with a structure. For example,TaxObligationERPByBusinessPartnerQueryMessage_Sync element structure65000 includes, among other things, MessageHeader 65006. Accordingly,heterogeneous applications may communicate using this consistent messageconfigured as such.

Additionally, FIGS. 66-1 through 66-8 illustrate one example logicalconfiguration of TaxObligationERPByBusinessPartnerResponseMessage_Syncelement structure 66000. Specifically, these figures depict thearrangement and hierarchy of various components such as one or morelevels of packages, entities, and datatypes, shown here as 66000 through66198. As described above, packages may be used to represent hierarchylevels. Entities are discrete business elements that are used during abusiness transaction. Data types are used to type object entities andinterfaces with a structure. For example,TaxObligationERPByBusinessPartnerResponseMessage_Sync element structure66000 includes, among other things, MessageHeader 66006. Accordingly,heterogeneous applications may communicate using this consistent messageconfigured as such.

Additionally, FIGS. 67-1 through 67-2 illustrate one example logicalconfiguration ofTaxObligationERPLevyTypeByBusinessPartnerQueryMessage_Sync elementstructure 67000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 67000 through 67042. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example,TaxObligationERPLevyTypeByBusinessPartnerQueryMessage_Sync elementstructure 67000 includes, among other things, MessageHeader 67006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIGS. 68-1 through 68-2 illustrate one example logicalconfiguration ofTaxObligationERPLevyTypeByBusinessPartnerResponseMessage_Sync elementstructure 68000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 68000 through 68050. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example,TaxObligationERPLevyTypeByBusinessPartnerResponseMessage_Sync elementstructure 68000 includes, among other things, MessageHeader 68006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIG. 69 illustrates one example logical configuration ofTaxObligationERPRegistrationFormByIdQueryMessage_Sync element structure69000. Specifically, this figure depicts the arrangement and hierarchyof various components such as one or more levels of packages, entities,and datatypes, shown here as 69000 through 69018. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example,TaxObligationERPRegistrationFormByIdQueryMessage_Sync element structure69000 includes, among other things, MessageHeader 69006. Accordingly,heterogeneous applications may communicate using this consistent messageconfigured as such.

Additionally, FIGS. 70-1 through 70-3 illustrate one example logicalconfiguration ofTaxObligationERPRegistrationFormByIdResponseMessage_Sync elementstructure 70000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 70000 through 70072. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example,TaxObligationERPRegistrationFormByIdResponseMessage_Sync elementstructure 70000 includes, among other things, MessageHeader 70006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIG. 71 illustrates one example logical configuration ofTaxObligationERPFilingObligationByIdQueryMessage element structure71000. Specifically, this figure depicts the arrangement and hierarchyof various components such as one or more levels of packages, entities,and datatypes, shown here as 71000 through 71018. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObligationERPFilingObligationByIdQueryMessageelement structure 71000 includes, among other things, MessageHeader71006. Accordingly, heterogeneous applications may communicate usingthis consistent message configured as such.

Additionally, FIGS. 72-1 through 72-5 illustrate one example logicalconfiguration ofTaxObligationERPFilingObligationByIdResponseMessage_Sync elementstructure 72000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 72000 through 72114. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example,TaxObligationERPFilingObligationByIdResponseMessage_Sync elementstructure 72000 includes, among other things, MessageHeader 72006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIG. 73 illustrates one example logical configuration ofTaxObligationERPByIdQueryMessage_Sync element structure 73000.Specifically, this figure depicts the arrangement and hierarchy ofvarious components such as one or more levels of packages, entities, anddatatypes, shown here as 73000 through 73018. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObligationERPByIdQueryMessage_Sync elementstructure 73000 includes, among other things, MessageHeader 73006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIGS. 74-1 through 74-12 illustrate one example logicalconfiguration of TaxObligationERPByIdResponseMessage_Sync elementstructure 74000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 74000 through 74294. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxObligationERPByIdResponseMessage_Sync elementstructure 74000 includes, among other things, MessageHeader 74006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

In further detail, FIGS. 54-1 through 54-15 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPMessage_sync 54000 package. TheTaxObligationERPMessage_sync 54000 package is a TxOblgnERPMsg 54004 datatype. The TaxObligationERPMessage_sync 54000 package includes aTaxObligationERPMessage_sync 54002 entity. TheTaxObligationERPMessage_sync 54000 package includes various packages,namely a MessageHeader 54006, a TaxObligation 54012, aProcessingConditions 54348 and a Log 54358.

The MessageHeader 54006 package is a BusinessDocumentMessageHeader 54010data type. The MessageHeader 54006 package includes a MessageHeader54008 entity.

The TaxObligation 54012 package is a TxOblgn 54016 data type. TheTaxObligation 54012 package includes a TaxObligation 54014 entity. TheTaxObligation 54012 package includes various packages, namely aFilingObligation 54102, a FilingRule 54180, a FilingExemption 54276, anInvoicingTerms 54302 and a RegistrationForm 54316. The TaxObligation54014 entity includes various attributes, namely an@filingObligationListCompleteTransmissionIndicator 54018, an@filingRuleListCompleteTransmissionIndicator 54022, an@filingExemptionListCompleteTransmissionIndicator 54026, an@registrationFormListCompleteTransmissionIndicator 54030, aTaxObligationID 54034, a TaxPayerPartyID 54038, a LevyTypeCode 54042, aLevyTypeName 54046, a StartBillingPeriodID 54050, aStartBillingPeriodName 54054, an EndBillingPeriodID 54058, anEndBillingPeriodName 54062, a ValidityStartDate 54066, a ValidityEndDate54070, a TaxObjectID 54074, a ContractAccountID 54078, aRegistrationStatusCode 54082, a RegistrationStatusName 54086, aContactPartyID 54090, an ElectronicFilingCode 54094 and anEmailReminderIndicator 54098.

The @filingObligationListCompleteTransmissionIndicator 54018 attributeis an Indicator 54020 data type. The@filingRuleListCompleteTransmissionIndicator 54022 attribute is anIndicator 54024 data type. The@filingExemptionListCompleteTransmissionIndicator 54026 attribute is anIndicator 54028 data type. The@registrationFormListCompleteTransmissionIndicator 54030 attribute is anIndicator 54032 data type. The TaxObligationID 54034 attribute is anIdentifier 54036 data type. An Identifier is a unique identification ofan object within an identification scheme that is managed by an agency.There are usually multiple identification schemes for identifying anobject.

The TaxPayerPartyID 54038 attribute is a PartyInternalID 54040 datatype. A BusinessPartnerinternalID is a unique proprietary identifier fora business partner. The Party ID here represents the Backend InternalBusiness Partner ID. The LevyTypeCode 54042 attribute is a LevyTypeCode54044 data type. A Code is a character string of letters, numbers,special characters (except escape sequences), and symbols. A coderepresents a definitive value, method, or a property description in anabbreviated or language-independent form. LevyTypeCode represents arevenue type.

The LevyTypeName 54046 attribute is a MEDIUM_Name 54048 data type.LevyTypeName is a revenue type name. The StartBillingPeriodID 54050attribute is a BillingPeriodID 54052 data type. StartBillingPeriodID isa key for period assignment (e.g., starting period). TheStartBillingPeriodName 54054 attribute is a MEDIUM_Name 54056 data type.MEDIUM_Description is a restriction on GDT Description to specify auniform length for descriptions of medium length. MEDIUM_Descriptioncontains the variable “MEDIUM_”, which may get replaced by one or morequalifiers. StartBillingPeriodName is text for a period key.

The EndBillingPeriodID 54058 attribute is a BillingPeriodID 54060 datatype. The EndBillingPeriodName 54062 attribute is a MEDIUM_Name 54064data type. MEDIUM_Description is a restriction on GDT Description tospecify a uniform length for descriptions of medium length.MEDIUM_Description contains the variable “MEDIUM_”, which gets replacedby one or more qualifiers. The ValidityStartDate 54066 attribute is aDate 54068 data type. A Date is a specification of an exact day in theGregorian calendar.

The ValidityEndDate 54070 attribute is a Date 54072 data type. A Date isa specification of an exact day in the Gregorian calendar. TheTaxObjectID 54074 attribute is an Identifier 54076 data type. TheContractAccountID 54078 attribute is a ContractAccountID 54080 datatype. A ContractAccountID is a unique identifier for a contract account.The RegistrationStatusCode 54082 attribute is a Code 54084 data type. Acode is a character string of letters, numbers, special characters(except escape sequences), and symbols. A code represents a definitivevalue, a method, or a property description in an abbreviated orlanguage-independent form. RegistrationStatusCode is a code for aregistration status.

The RegistrationStatusName 54086 attribute is a MEDIUM_Name 54088 datatype. MEDIUM_Description is a restriction on GDT Description to specifya uniform length for descriptions of medium length. MEDIUM_Descriptioncontains the variable “MEDIUM_”, which gets replaced by one or morequalifiers. RegistrationStatusName is text for a registration status.The ContactPartyID 54090 attribute is a PartyInternalID 54092 data type.The ElectronicFilingCode 54094 attribute is a Code 54096 data type. Codeis a character string of letters, numbers, special characters (exceptescape sequences), and symbols. A code represents a definitive value, amethod, or a property description in an abbreviated orlanguage-independent form. The EmailReminderIndicator 54098 attribute isan Indicator 54100 data type. The FilingObligation 54102 package is aTxOblgnFilngOblgn 54106 data type.

The FilingObligation 54102 package includes a FilingObligation 54104entity. The FilingObligation 54104 entity includes various attributes,namely an @actionCode 54108, an InboundCorrespondenceCategoryCode 54112,an InboundCorrespondenceCategoryName 54116, a BillingPeriodID 54120, aBillingPeriodName 54124, a BillingStartDate 54128, aCorrespondenceStatusCode 54132, a CorrespondenceStatusName 54136, anInboundCorrespondenceDueDate 54140, an InboundCorrespondenceReceivedDate54144, an InboundCorrespondenceDeferraIDate 54148, a BillingEndDate54152, a ClearingReasonCode 54156, a ClearingReasonName 54160, an Amount54164, a CurrencyCode 54168, a CurrencyName 54172 and aCorrespondingTaxReturnID 54176.

The @actionCode 54108 attribute is an ActionCode 54110 data type. TheInboundCorrespondenceCategoryCode 54112 attribute is a Code 54114 datatype. A code is a character string of letters, numbers, specialcharacters (except escape sequences), and symbols. A code represents adefinitive value, a method, or a property description in an abbreviatedor language-independent form. InboundCorrespondenceCategoryCode is acode for an inbound correspondence category. TheInboundCorrespondenceCategoryName 54116 attribute is a MEDIUM_Name 54118data type. MEDIUM_Description is a restriction on GDT Description tospecify a uniform length for descriptions of medium length.MEDIUM_Description contains the variable “MEDIUM_”, which gets replacedby one or more qualifiers. InboundCorrespondenceCategoryName is a namefor an inbound correspondence category.

The BillingPeriodID 54120 attribute is a BillingPeriodID 54122 datatype. BillingPeriodID is a key for a period assignment. TheBillingPeriodName 54124 attribute is a MEDIUM_Name 54126 data type.MEDIUM_Description is a restriction on GDT Description to specify auniform length for descriptions of medium length. MEDIUM_Descriptioncontains the variable “MEDIUM_”, which gets replaced by one or morequalifiers. The BillingStartDate 54128 attribute is a Date 54130 datatype. A Date is the specification of an exact day in the Gregoriancalendar. BillingStartDate is a lower limit of a settlement period, andmay be used for frequent filers. The start and end date may be derivedfrom the period key. In some implementations, if different periods areused (e.g., if a company is allowed to file slightly differently),BillingStartDate may be stored on a contract object, more than one startdate for a given period may exist, and one of the start dates may bespecified.

The CorrespondenceStatusCode 54132 attribute is a Code 54134 data type.A code is a character string of letters, numbers, special characters(except escape sequences), and symbols. A code represents a definitivevalue, a method, or a property description in an abbreviated orlanguage-independent form. CorrespondenceStatusCode is a code for acorrespondence status. The CorrespondenceStatusName 54136 attribute is aMEDIUM_Name 54138 data type. MEDIUM_Description is a restriction on GDTDescription to specify a uniform length for descriptions of mediumlength. MEDIUM_Description contains the variable “MEDIUM_”, which getsreplaced by one or more qualifiers.

The InboundCorrespondenceDueDate 54140 attribute is a Date 54142 datatype. A Date is a specification of an exact day in the Gregoriancalendar. InboundCorrespondenceDueDate is a due date for an inboundcorrespondence. The InboundCorrespondenceReceivedDate 54144 attribute isa Date 54146 data type. A Date is a specification of an exact day in theGregorian calendar. InboundCorrespondenceReceivedDate is a date ofreceipt for an inbound correspondence. TheInboundCorrespondenceDeferraIDate 54148 attribute is a Date 54150 datatype. A Date is a specification of an exact day in the Gregoriancalendar. InboundCorrespondenceDeferraIDate is a date of a deferral ofan inbound correspondence. The BillingEndDate 54152 attribute is a Date54154 data type. A Date is a specification of an exact day in theGregorian calendar. BillingEndDate is an upper limit of a calculationperiod.

The ClearingReasonCode 54156 attribute is a Code 54158 data type. A codeis a character string of letters, numbers, special characters (exceptescape sequences), and symbols. A code represents a definitive value, amethod, or a property description in an abbreviated orlanguage-independent form. ClearingReasonCode is a code for a clearingreason of an inbound correspondence. The ClearingReasonName 54160attribute is a MEDIUM_Name 54162 data type. MEDIUM_Description is arestriction on GDT Description to specify a uniform length fordescriptions of medium length. MEDIUM_Description contains the variable“MEDIUM_”, which gets replaced by one or more qualifiers.

The Amount 54164 attribute is an Amount 54166 data type. Amount is anamount with a corresponding currency unit. An Amount may be an amount inlocal currency with plus and minus signs. Amount may be derived in anevent, if not specified directly. The CurrencyCode 54168 attribute is aCurrencyCode 54170 data type. CurrencyCode is a coded representation ofa currency. The CurrencyName 54172 attribute is a MEDIUM_Name 54174 datatype. MEDIUM_Description is a restriction on GDT Description to specifya uniform length for descriptions of medium length. MEDIUM_Descriptioncontains the variable “MEDIUM_”, which gets replaced by one or morequalifiers. CurrentName is a name of a currency key. TheCorrespondingTaxReturnID 54176 attribute is an Identifier 54178 datatype. CorrespondingTaxReturnID is a unique identifier of a correspondingtax return.

The FilingRule 54180 package is a TxOblgnFilngRule 54184 data type. TheFilingRule 54180 package includes a FilingRule 54182 entity. TheFilingRule 54180 package includes a Periodicity 54218 package. TheFilingRule 54182 entity includes various attributes, namely an@deviatingPeriodListCompleteTransmissionIndicator 54186, an@standardPeriodListCompleteTransmissionIndicator 54190, an @actionCode54194, an InboundCorrespondenceCategoryCode 54198, anInboundCorrespondenceFirstBillingPeriodID 54202, a GenerationStatusCode54206, a GenerationStatusName 54210 and anInboundCorrespondenceLastBillingPeriodID 54214.

The @deviatingPeriodListCompleteTransmissionIndicator 54186 attribute isan Indicator 54188 data type. The@standardPeriodListCompleteTransmissionIndicator 54190 attribute is anIndicator 54192 data type. The @actionCode 54194 attribute is anActionCode 54196 data type. A code is a character string of letters,numbers, special characters (except escape sequences), and symbols. Acode represents a definitive value, a method, or a property descriptionin an abbreviated or language-independent form. TheInboundCorrespondenceCategoryCode 54198 attribute is a Code 54200 datatype. A code is a character string of letters, numbers, specialcharacters (except escape sequences), and symbols. A code represents adefinitive value, a method, or a property description in an abbreviatedor language-independent form. InboundCorrespondenceCategoryCode is acode for an inbound correspondence category.

The InboundCorrespondenceFirstBillingPeriodID 54202 attribute is aBillingPeriodID 54204 data type. A code is a character string ofletters, numbers, special characters (except escape sequences), andsymbols. A code represents a definitive value, a method, or a propertydescription in an abbreviated or language-independent form. TheGenerationStatusCode 54206 attribute is a Code 54208 data type. A codeis a character string of letters, numbers, special characters (exceptescape sequences), and symbols. A code represents a definitive value, amethod, or a property description in an abbreviated orlanguage-independent form.

The GenerationStatusName 54210 attribute is a MEDIUM_Name 54212 datatype. MEDIUM_Description is a restriction on GDT Description to specifya uniform length for descriptions of medium length. MEDIUM_Descriptioncontains the variable “MEDIUM_”, which gets replaced by one or morequalifiers. The InboundCorrespondenceLastBillingPeriodID 54214 attributeis a BillingPeriodID 54216 data type.InboundCorrespondenceLastBillingPeriodID is a unique identifier of alast billing period associated with an inbound correspondence.

The Periodicity 54218 package is a TxOblgnFilngRuleDevtngPer 54222 datatype. The Periodicity 54218 package includes various entities, namely aDeviatingPeriod 54220 and a StandardPeriod 54248. The DeviatingPeriod54220 entity includes various attributes, namely an @actionCode 54224, aStartDate 54228, an EndDate 54232, a DueDate 54236, a BillingPeriodID54240 and a BillingPeriodName 54244.

The @actionCode 54224 attribute is an ActionCode 54226 data type. TheStartDate 54228 attribute is a Date 54230 data type. A Date is aspecification of an exact day in the Gregorian calendar. The EndDate54232 attribute is a Date 54234 data type. A Date is a specification ofan exact day in the Gregorian calendar. The DueDate 54236 attribute is aDate 54238 data type. A Date is a specification of an exact day in theGregorian calendar.

The BillingPeriodID 54240 attribute is a BillingPeriodID 54242 datatype. The BillingPeriodName 54244 attribute is a MEDIUM_Name 54246 datatype. BillingPeriodName is a MEDIUM_Name. The StandardPeriod 54248entity includes various attributes, namely an @actionCode 54252, aStartDate 54256, an EndDate 54260, a DueDate 54264, a BillingPeriodID54268 and a BillingPeriodName 54272. The @actionCode 54252 attribute isan ActionCode 54254 data type. The StartDate 54256 attribute is a Date54258 data type. A Date is a specification of an exact day in theGregorian calendar.

The EndDate 54260 attribute is a Date 54262 data type. A Date is aspecification of an exact day in the Gregorian calendar. The DueDate54264 attribute is a Date 54266 data type. A Date is a specification ofan exact day in the Gregorian calendar. The BillingPeriodID 54268attribute is a BillingPeriodID 54270 data type. The BillingPeriodName54272 attribute is a MEDIUM_Name 54274 data type. BillingPeriodName is aMEDIUM_Name.

The FilingExemption 54276 package is a TxOblgnFilngExmp 54280 data type.The FilingExemption 54276 package includes a FilingExemption 54278entity. The FilingExemption 54278 entity includes various attributes,namely an @actionCode 54282, a StartDay 54286, a StartMonth 54290, anEndDay 54294 and an EndMonth 54298.

The @actionCode 54282 attribute is an ActionCode 54284 data type. TheStartDay 54286 attribute is a DayOfMonth 54288 data type. Numeric is adecimal value. StartDay is an exception period start date. TheStartMonth 54290 attribute is a Month 54292 data type. Numeric is adecimal value. StartMonth is an exception period start month. The EndDay54294 attribute is a DayOfMonth 54296 data type. Numeric is a decimalvalue. EndDay is an exception period end day. The EndMonth 54298attribute is a Month 54300 data type. Numeric is a decimal value.EndMonth is an exception period end month.

The InvoicingTerms 54302 package is a TxOblgnInvcgTrms 54306 data type.The InvoicingTerms 54302 package includes an InvoicingTerms 54304entity. The InvoicingTerms 54304 entity includes various attributes,namely a ContractAccountContractReferenceID 54308 and a ChargePercent54312.

The ContractAccountContractReferenceID 54308 attribute is a Numeric54310 data type. Numeric is a decimal value. The ChargePercent 54312attribute is a Percent 54314 data type. Quantity is a non-monetarynumerical specification of an amount in a unit of measurement.

The RegistrationForm 54316 package is a TxOblgnRegistnForm 54320 datatype. The RegistrationForm 54316 package includes a RegistrationForm54318 entity. The RegistrationForm 54316 package includes aPropertyValuation 54338 package. There may be multiple registrationforms for one tax obligation. Depending on the type of business, datamay be provided on one ‘form’, but the one ‘form’ may include other‘forms’ as well. For example, registration of a petrol station mayinvolve a usual registration form and an additional form for licensing.

The RegistrationForm 54318 entity includes various attributes, namely an@actionCode 54322, a FormTemplateID 54326, a FormVersionID 54330 and aFormStatusCode 54334. The @actionCode 54322 attribute is an ActionCode54324 data type. The FormTemplateID 54326 attribute is an Identifier54328 data type. FormTemplateID is a key for a scenario and is aninternal service request template. The FormVersionID 54330 attribute isan Identifier 54332 data type.

The FormStatusCode 54334 attribute is a Code 54336 data type. Code is acharacter string of letters, numbers, special characters (except escapesequences), and symbols. Code represents a definitive value, a method,or a property description in an abbreviated or language-independentform. The PropertyValuation 54338 package is aTxOblgnRegistnFormProptyValn 54342 data type. The PropertyValuation54338 package includes a PropertyValuation 54340 entity. ThePropertyValuation 54340 entity includes a PropertyValuation 54344attribute. The PropertyValuation 54344 attribute is a PropertyValuation54346 data type.

The ProcessingConditions 54348 package is a QueryProcessingConditions54352 data type. The ProcessingConditions 54348 package includes variousentities, namely a QueryProcessingConditions 54350 and aResponseProcessingConditions 54354.

The Log 54358 package is a Log 54362 data type. The Log 54358 packageincludes a Log 54360 entity. Log is a sequence of messages that resultwhen an application executes a task.

In further detail, FIGS. 55-1 through 55-7 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPChangeRequestMessage_Sync 55000 package. TheTaxObligationERPChangeRequestMessage_Sync 55000 package includes aTaxObligationERPChangeRequestMessage_Sync 55002 entity. TheTaxObligationERPChangeRequestMessage_Sync 55000 package includes variouspackages, namely a MessageHeader 55004 and a TaxObligation 55010.

The MessageHeader 55004 package includes a MessageHeader 55006 entity.The MessageHeader 55006 entity has a cardinality of 1 55008 meaning thatfor each instance of the MessageHeader 55004 package there is oneMessageHeader 55006 entity.

The TaxObligation 55010 package includes a TaxObligation 55012 entity.The TaxObligation 55010 package includes various packages, namely aFilingRule 55048, a FilingExemption 55104, an InvoicingTerms 55130 and aRegistrationForm 55144.

The TaxObligation 55012 entity has a cardinality of 1 55014 meaning thatfor each instance of the TaxObligation 55010 package there is oneTaxObligation 55012 entity. The TaxObligation 55012 entity includesvarious attributes, namely an@filingRuleListCompleteTransmissionIndicator 55016, an@filingExemptionListCompleteTransmissionIndicator 55020, an@registrationFormListCompleteTransmissionIndicator 55024, aTaxObligationID 55028, a RegistrationStatusName 55032, a ContactPartyID55036, an ElectronicFilingCode 55040 and an EmailReminderIndicator55044. The @filingRuleListCompleteTransmissionIndicator 55016 attributehas a cardinality of 1 55018 meaning that for each instance of theTaxObligation 55012 entity there is one@filingRuleListCompleteTransmissionIndicator 55016 attribute. The@filingExemptionListCompleteTransmissionIndicator 55020 attribute has acardinality of 1 55022 meaning that for each instance of theTaxObligation 55012 entity there is one@filingExemptionListCompleteTransmissionIndicator 55020 attribute. The@registrationFormListCompleteTransmissionIndicator 55024 attribute has acardinality of 1 55026 meaning that for each instance of theTaxObligation 55012 entity there is one@registrationFormListCompleteTransmissionIndicator 55024 attribute. TheTaxObligationID 55028 attribute has a cardinality of 1 55030 meaningthat for each instance of the TaxObligation 55012 entity there is oneTaxObligationID 55028 attribute. The RegistrationStatusName 55032attribute has a cardinality of 0 . . . 1 55034 meaning that for eachinstance of the TaxObligation 55012 entity there may be oneRegistrationStatusName 55032 attribute. The ContactPartyID 55036attribute has a cardinality of 0 . . . n 55038 meaning that for eachinstance of the TaxObligation 55012 entity there may be one or moreContactPartyID 55036 attributes. The ElectronicFilingCode 55040attribute has a cardinality of 0 . . . 1 55042 meaning that for eachinstance of the TaxObligation 55012 entity there may be oneElectronicFilingCode 55040 attribute. The EmailReminderIndicator 55044attribute has a cardinality of 0 . . . 1 55046 meaning that for eachinstance of the TaxObligation 55012 entity there may be oneEmailReminderIndicator 55044 attribute.

The FilingRule 55048 package includes a FilingRule 55050 entity. TheFilingRule 55048 package includes a Periodicity 55078 package. TheFilingRule 55050 entity has a cardinality of 0 . . . n 55052 meaningthat for each instance of the FilingRule 55048 package there may be oneor more FilingRule 55050 entities. The FilingRule 55050 entity includesvarious attributes, namely an@deviatingPeriodListCompleteTransmissionIndicator 55054, an @actionCode55058, an InboundCorrespondenceCategoryCode 55062, anInboundCorrespondenceFirstBillingPeriodID 55066, a GenerationStatusCode55070 and an InboundCorrespondenceLastBillingPeriodID 55074. The@deviatingPeriodListCompleteTransmissionIndicator 55054 attribute has acardinality of 1 55056 meaning that for each instance of the FilingRule55050 entity there is one@deviatingPeriodListCompleteTransmissionIndicator 55054 attribute. The@actionCode 55058 attribute has a cardinality of 1 55060 meaning thatfor each instance of the FilingRule 55050 entity there is one@actionCode 55058 attribute. The InboundCorrespondenceCategoryCode 55062attribute has a cardinality of 1 55064 meaning that for each instance ofthe FilingRule 55050 entity there is oneInboundCorrespondenceCategoryCode 55062 attribute. TheInboundCorrespondenceFirstBillingPeriodID 55066 attribute has acardinality of 1 55068 meaning that for each instance of the FilingRule55050 entity there is one InboundCorrespondenceFirstBillingPeriodID55066 attribute. The GenerationStatusCode 55070 attribute has acardinality of 0 . . . 1 55072 meaning that for each instance of theFilingRule 55050 entity there may be one GenerationStatusCode 55070attribute. The InboundCorrespondenceLastBillingPeriodID 55074 attributehas a cardinality of 0 . . . 1 55076 meaning that for each instance ofthe FilingRule 55050 entity there may be oneInboundCorrespondenceLastBillingPeriodID 55074 attribute.

The Periodicity 55078 package includes a DeviatingPeriod 55080 entity.The DeviatingPeriod 55080 entity has a cardinality of 0 . . . n 55082meaning that for each instance of the Periodicity 55078 package theremay be one or more DeviatingPeriod 55080 entities. The DeviatingPeriod55080 entity includes various attributes, namely an @actionCode 55084, aStartDate 55088, an EndDate 55092, a DueDate 55096 and a BillingPeriodID55100. The @actionCode 55084 attribute has a cardinality of 1 55086meaning that for each instance of the DeviatingPeriod 55080 entity thereis one @actionCode 55084 attribute. The StartDate 55088 attribute has acardinality of 1 55090 meaning that for each instance of theDeviatingPeriod 55080 entity there is one StartDate 55088 attribute. TheEndDate 55092 attribute has a cardinality of 0 . . . 1 55094 meaningthat for each instance of the DeviatingPeriod 55080 entity there may beone EndDate 55092 attribute. The DueDate 55096 attribute has acardinality of 0 . . . 1 55098 meaning that for each instance of theDeviatingPeriod 55080 entity there may be one DueDate 55096 attribute.The BillingPeriodID 55100 attribute has a cardinality of 1 55102 meaningthat for each instance of the DeviatingPeriod 55080 entity there is oneBillingPeriodID 55100 attribute.

The FilingExemption 55104 package includes a FilingExemption 55106entity. The FilingExemption 55106 entity has a cardinality of 0 . . . n55108 meaning that for each instance of the FilingExemption 55104package there may be one or more FilingExemption 55106 entities. TheFilingExemption 55106 entity includes various attributes, namely an@actionCode 55110, a StartDay 55114, a StartMonth 55118, an EndDay 55122and an EndMonth 55126. The @actionCode 55110 attribute has a cardinalityof 1 55112 meaning that for each instance of the FilingExemption 55106entity there is one @actionCode 55110 attribute. The StartDay 55114attribute has a cardinality of 1 55116 meaning that for each instance ofthe FilingExemption 55106 entity there is one StartDay 55114 attribute.The StartMonth 55118 attribute has a cardinality of 1 55120 meaning thatfor each instance of the FilingExemption 55106 entity there is oneStartMonth 55118 attribute. The EndDay 55122 attribute has a cardinalityof 1 55124 meaning that for each instance of the FilingExemption 55106entity there is one EndDay 55122 attribute. The EndMonth 55126 attributehas a cardinality of 1 55128 meaning that for each instance of theFilingExemption 55106 entity there is one EndMonth 55126 attribute.

The InvoicingTerms 55130 package includes an InvoicingTerms 55132entity.

The InvoicingTerms 55132 entity has a cardinality of 0 . . . 1 55134meaning that for each instance of the InvoicingTerms 55130 package theremay be one InvoicingTerms 55132 entity. The InvoicingTerms 55132 entityincludes various attributes, namely a ContractAccountContractReferenceID55136 and a ChargePercent 55140. The ContractAccountContractReferenceID55136 attribute has a cardinality of 0 . . . 1 55138 meaning that foreach instance of the InvoicingTerms 55132 entity there may be oneContractAccountContractReferenceID 55136 attribute. The ChargePercent55140 attribute has a cardinality of 1 55142 meaning that for eachinstance of the InvoicingTerms 55132 entity there is one ChargePercent55140 attribute.

The RegistrationForm 55144 package includes a RegistrationForm 55146entity. The RegistrationForm 55144 package includes a PropertyValuation55166 package. The RegistrationForm 55146 entity has a cardinality of 0. . . n 55148 meaning that for each instance of the RegistrationForm55144 package there may be one or more RegistrationForm 55146 entities.The RegistrationForm 55146 entity includes various attributes, namely an@actionCode 55150, a FormTemplateID 55154, a FormVersionID 55158 and aFormStatusCode 55162. The @actionCode 55150 attribute has a cardinalityof 1 55152 meaning that for each instance of the RegistrationForm 55146entity there is one @actionCode 55150 attribute. The FormTemplateID55154 attribute has a cardinality of 1 55156 meaning that for eachinstance of the RegistrationForm 55146 entity there is oneFormTemplateID 55154 attribute. The FormVersionID 55158 attribute has acardinality of 1 55160 meaning that for each instance of theRegistrationForm 55146 entity there is one FormVersionID 55158attribute. The FormStatusCode 55162 attribute has a cardinality of 0 . .. 1 55164 meaning that for each instance of the RegistrationForm 55146entity there may be one FormStatusCode 55162 attribute.

The PropertyValuation 55166 package includes a PropertyValuation 55168entity. The PropertyValuation 55168 entity has a cardinality of 1 . . .n 55170 meaning that for each instance of the PropertyValuation 55166package there are one or more PropertyValuation 55168 entities. ThePropertyValuation 55168 entity includes a PropertyValuation 55172attribute. The PropertyValuation 55172 attribute has a cardinality of 0. . . 1 55174 meaning that for each instance of the PropertyValuation55168 entity there may be one PropertyValuation 55172 attribute.

The data types of the various packages, entities, and attributes aredescribed with respect to FIG. 54.

In further detail, FIGS. 56-1 through 56-9 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPChangeConfirmationMessage_Sync 56000 package. TheTaxObligationERPChangeConfirmationMessage_Sync 56000 package includes aTaxObligationERPChangeConfirmationMessage_Sync 56002 entity. TheTaxObligationERPChangeConfirmationMessage_Sync 56000 package includesvarious packages, namely a MessageHeader 56004, a TaxObligation 56010and a Log 56220.

The MessageHeader 56004 package includes a MessageHeader 56006 entity.The MessageHeader 56006 entity has a cardinality of 1 56008 meaning thatfor each instance of the MessageHeader 56004 package there is oneMessageHeader 56006 entity.

The TaxObligation 56010 package includes a TaxObligation 56012 entity.The TaxObligation 56010 package includes various packages, namely aFilingRule 56080, a FilingExemption 56156, an InvoicingTerms 56178 and aRegistrationForm 56192.

The TaxObligation 56012 entity has a cardinality of 0 . . . 1 56014meaning that for each instance of the TaxObligation 56010 package theremay be one TaxObligation 56012 entity. The TaxObligation 56012 entityincludes various attributes, namely a TaxObligationID 56016, aTaxPayerPartyID 56020, a LevyTypeCode 56024, a LevyTypeName 56028, aStartBillingPeriodID 56032, a StartBillingPeriodName 56036, anEndBillingPeriodID 56040, an EndBillingPeriodName 56044, aValidityStartDate 56048, a ValidityEndDate 56052, a ContractAccountID56056, a RegistrationStatusCode 56060, a RegistrationStatusName 56064, aContactPartyID 56068, an ElectronicFilingCode 56072 and anEmailReminderIndicator 56076. The TaxObligationID 56016 attribute has acardinality of 1 56018 meaning that for each instance of theTaxObligation 56012 entity there is one TaxObligationID 56016 attribute.The TaxPayerPartyID 56020 attribute has a cardinality of 1 56022 meaningthat for each instance of the TaxObligation 56012 entity there is oneTaxPayerPartyID 56020 attribute. The LevyTypeCode 56024 attribute has acardinality of 1 56026 meaning that for each instance of theTaxObligation 56012 entity there is one LevyTypeCode 56024 attribute.The LevyTypeName 56028 attribute has a cardinality of 0 . . . 1 56030meaning that for each instance of the TaxObligation 56012 entity theremay be one LevyTypeName 56028 attribute. The StartBillingPeriodID 56032attribute has a cardinality of 1 56034 meaning that for each instance ofthe TaxObligation 56012 entity there is one StartBillingPeriodID 56032attribute. The StartBillingPeriodName 56036 attribute has a cardinalityof 0 . . . 1 56038 meaning that for each instance of the TaxObligation56012 entity there may be one StartBillingPeriodName 56036 attribute.The EndBillingPeriodID 56040 attribute has a cardinality of 0 . . . 156042 meaning that for each instance of the TaxObligation 56012 entitythere may be one EndBillingPeriodID 56040 attribute. TheEndBillingPeriodName 56044 attribute has a cardinality of 0 . . . 156046 meaning that for each instance of the TaxObligation 56012 entitythere may be one EndBillingPeriodName 56044 attribute. TheValidityStartDate 56048 attribute has a cardinality of 0 . . . 1 56050meaning that for each instance of the TaxObligation 56012 entity theremay be one ValidityStartDate 56048 attribute.

The ValidityEndDate 56052 attribute has a cardinality of 0 . . . 1 56054meaning that for each instance of the TaxObligation 56012 entity theremay be one ValidityEndDate 56052 attribute. The ContractAccountID 56056attribute has a cardinality of 1 56058 meaning that for each instance ofthe TaxObligation 56012 entity there is one ContractAccountID 56056attribute. The RegistrationStatusCode 56060 attribute has a cardinalityof 1 56062 meaning that for each instance of the TaxObligation 56012entity there is one RegistrationStatusCode 56060 attribute. TheRegistrationStatusName 56064 attribute has a cardinality of 0 . . . 156066 meaning that for each instance of the TaxObligation 56012 entitythere may be one RegistrationStatusName 56064 attribute. TheContactPartyID 56068 attribute has a cardinality of 0 . . . n 56070meaning that for each instance of the TaxObligation 56012 entity theremay be one or more ContactPartyID 56068 attributes. TheElectronicFilingCode 56072 attribute has a cardinality of 0 . . . 156074 meaning that for each instance of the TaxObligation 56012 entitythere may be one ElectronicFilingCode 56072 attribute. TheEmailReminderIndicator 56076 attribute has a cardinality of 1 56078meaning that for each instance of the TaxObligation 56012 entity thereis one EmailReminderIndicator 56076 attribute.

The FilingRule 56080 package includes a FilingRule 56082 entity. TheFilingRule 56080 package includes a Periodicity 56106 package.

The FilingRule 56082 entity has a cardinality of 0 . . . n 56084 meaningthat for each instance of the FilingRule 56080 package there may be oneor more FilingRule 56082 entities. The FilingRule 56082 entity includesvarious attributes, namely an InboundCorrespondenceCategoryCode 56086,an InboundCorrespondenceFirstBillingPeriodID 56090, aGenerationStatusCode 56094, a GenerationStatusName 56098 and anInboundCorrespondenceLastBillingPeriodID 56102. TheInboundCorrespondenceCategoryCode 56086 attribute has a cardinality of 156088 meaning that for each instance of the FilingRule 56082 entitythere is one InboundCorrespondenceCategoryCode 56086 attribute. TheInboundCorrespondenceFirstBillingPeriodID 56090 attribute has acardinality of 1 56092 meaning that for each instance of the FilingRule56082 entity there is one InboundCorrespondenceFirstBillingPeriodID56090 attribute. The GenerationStatusCode 56094 attribute has acardinality of 1 56096 meaning that for each instance of the FilingRule56082 entity there is one GenerationStatusCode 56094 attribute. TheGenerationStatusName 56098 attribute has a cardinality of 0 . . . 156100 meaning that for each instance of the FilingRule 56082 entitythere may be one GenerationStatusName 56098 attribute. TheInboundCorrespondenceLastBillingPeriodID 56102 attribute has acardinality of 0 . . . 1 56104 meaning that for each instance of theFilingRule 56082 entity there may be oneInboundCorrespondenceLastBillingPeriodID 56102 attribute.

The Periodicity 56106 package includes various entities, namely aDeviatingPeriod 56108 and a StandardPeriod 56132. The DeviatingPeriod56108 entity has a cardinality of 0 . . . n 56110 meaning that for eachinstance of the Periodicity 56106 package there may be one or moreDeviatingPeriod 56108 entities. The DeviatingPeriod 56108 entityincludes various attributes, namely a StartDate 56112, an EndDate 56116,a DueDate 56120, a BillingPeriodID 56124 and a BillingPeriodName 56128.The StartDate 56112 attribute has a cardinality of 1 56114 meaning thatfor each instance of the DeviatingPeriod 56108 entity there is oneStartDate 56112 attribute. The EndDate 56116 attribute has a cardinalityof 1 56118 meaning that for each instance of the DeviatingPeriod 56108entity there is one EndDate 56116 attribute. The DueDate 56120 attributehas a cardinality of 0 . . . 1 56122 meaning that for each instance ofthe DeviatingPeriod 56108 entity there may be one DueDate 56120attribute. The BillingPeriodID 56124 attribute has a cardinality of 156126 meaning that for each instance of the DeviatingPeriod 56108 entitythere is one BillingPeriodID 56124 attribute. The BillingPeriodName56128 attribute has a cardinality of 0 . . . 1 56130 meaning that foreach instance of the DeviatingPeriod 56108 entity there may be oneBillingPeriodName 56128 attribute.

The StandardPeriod 56132 entity has a cardinality of 1 . . . n 56134meaning that for each instance of the Periodicity 56106 package thereare one or more StandardPeriod 56132 entities. The StandardPeriod 56132entity includes various attributes, namely a StartDate 56136, an EndDate56140, a DueDate 56144, a BillingPeriodID 56148 and a BillingPeriodName56152. The StartDate 56136 attribute has a cardinality of 1 56138meaning that for each instance of the StandardPeriod 56132 entity thereis one StartDate 56136 attribute. The EndDate 56140 attribute has acardinality of 1 56142 meaning that for each instance of theStandardPeriod 56132 entity there is one EndDate 56140 attribute. TheDueDate 56144 attribute has a cardinality of 0 . . . 1 56146 meaningthat for each instance of the StandardPeriod 56132 entity there may beone DueDate 56144 attribute. The BillingPeriodID 56148 attribute has acardinality of 1 56150 meaning that for each instance of theStandardPeriod 56132 entity there is one BillingPeriodID 56148attribute. The BillingPeriodName 56152 attribute has a cardinality of 0. . . 1 56154 meaning that for each instance of the StandardPeriod 56132entity there may be one BillingPeriodName 56152 attribute.

The FilingExemption 56156 package includes a FilingExemption 56158entity. The FilingExemption 56158 entity has a cardinality of 0 . . . n56160 meaning that for each instance of the FilingExemption 56156package there may be one or more FilingExemption 56158 entities. TheFilingExemption 56158 entity includes various attributes, namely aStartDay 56162, a StartMonth 56166, an EndDay 56170 and an EndMonth56174. The StartDay 56162 attribute has a cardinality of 1 56164 meaningthat for each instance of the FilingExemption 56158 entity there is oneStartDay 56162 attribute. The StartMonth 56166 attribute has acardinality of 1 56168 meaning that for each instance of theFilingExemption 56158 entity there is one StartMonth 56166 attribute.The EndDay 56170 attribute has a cardinality of 1 56172 meaning that foreach instance of the FilingExemption 56158 entity there is one EndDay56170 attribute. The EndMonth 56174 attribute has a cardinality of 156176 meaning that for each instance of the FilingExemption 56158 entitythere is one EndMonth 56174 attribute.

The InvoicingTerms 56178 package includes an InvoicingTerms 56180entity. The InvoicingTerms 56180 entity has a cardinality of 1 56182meaning that for each instance of the InvoicingTerms 56178 package thereis one InvoicingTerms 56180 entity. The InvoicingTerms 56180 entityincludes various attributes, namely a ContractAccountContractReferenceID56184 and a ChargePercent 56188. The ContractAccountContractReferenceID56184 attribute has a cardinality of 0 . . . 1 56186 meaning that foreach instance of the InvoicingTerms 56180 entity there may be oneContractAccountContractReferenceID 56184 attribute. The ChargePercent56188 attribute has a cardinality of 1 56190 meaning that for eachinstance of the InvoicingTerms 56180 entity there is one ChargePercent56188 attribute.

The RegistrationForm 56192 package includes a RegistrationForm 56194entity. The RegistrationForm 56192 package includes a PropertyValuation56210 package. The RegistrationForm 56194 entity has a cardinality of 0. . . n 56196 meaning that for each instance of the RegistrationForm56192 package there may be one or more RegistrationForm 56194 entities.The RegistrationForm 56194 entity includes various attributes, namely aFormTemplateID 56198, a FormVersionID 56202 and a FormStatusCode 56206.The FormTemplateID 56198 attribute has a cardinality of 1 56200 meaningthat for each instance of the RegistrationForm 56194 entity there is oneFormTemplateID 56198 attribute. The FormVersionID 56202 attribute has acardinality of 1 56204 meaning that for each instance of theRegistrationForm 56194 entity there is one FormVersionID 56202attribute. The FormStatusCode 56206 attribute has a cardinality of 0 . .. 1 56208 meaning that for each instance of the RegistrationForm 56194entity there may be one FormStatusCode 56206 attribute.

The PropertyValuation 56210 package includes a PropertyValuation 56212entity. The PropertyValuation 56212 entity has a cardinality of 1 . . .n 56214 meaning that for each instance of the PropertyValuation 56210package there are one or more PropertyValuation 56212 entities. ThePropertyValuation 56212 entity includes a PropertyValuation 56216attribute. The PropertyValuation 56216 attribute has a cardinality of 0. . . 1 56218 meaning that for each instance of the PropertyValuation56212 entity there may be one PropertyValuation 56216 attribute.

The Log 56220 package includes a Log 56222 entity. The Log 56222 entityhas a cardinality of 1 56224 meaning that for each instance of the Log56220 package there is one Log 56222 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 54.

In further detail, FIGS. 57-1 through 57-3 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPFilingObligationChangeRequestMessage_Sync 57000 package.The TaxObligationERPFilingObligationChangeRequestMessage_Sync 57000package includes aTaxObligationERPFilingObligationChangeRequestMessage_Sync 57002 entity.The TaxObligationERPFilingObligationChangeRequestMessage_Sync 57000package includes various packages, namely a MessageHeader 57004 and aTaxObligation 57010.

The MessageHeader 57004 package includes a MessageHeader 57006 entity.The MessageHeader 57006 entity has a cardinality of 1 57008 meaning thatfor each instance of the MessageHeader 57004 package there is oneMessageHeader 57006 entity.

The TaxObligation 57010 package includes a TaxObligation 57012 entity.The TaxObligation 57010 package includes a FilingObligation 57024package. The TaxObligation 57012 entity has a cardinality of 1 57014meaning that for each instance of the TaxObligation 57010 package thereis one TaxObligation 57012 entity. The TaxObligation 57012 entityincludes various attributes, namely an@filingObligationListCompleteTransmissionIndicator 57016 and aTaxObligationID 57020. The@filingObligationListCompleteTransmissionIndicator 57016 attribute has acardinality of 1 57018 meaning that for each instance of theTaxObligation 57012 entity there is one@filingObligationListCompleteTransmissionIndicator 57016 attribute. TheTaxObligationID 57020 attribute has a cardinality of 1 57022 meaningthat for each instance of the TaxObligation 57012 entity there is oneTaxObligationID 57020 attribute.

The FilingObligation 57024 package includes a FilingObligation 57026entity. The FilingObligation 57026 entity has a cardinality of 0 . . . n57028 meaning that for each instance of the FilingObligation 57024package there may be one or more FilingObligation 57026 entities. TheFilingObligation 57026 entity includes various attributes, namely an@actionCode 57030, an InboundCorrespondenceCategoryCode 57034, aBillingPeriodID 57038, a BillingStartDate 57042, aCorrespondenceStatusCode 57046, an InboundCorrespondenceDueDate 57050,an InboundCorrespondenceReceivedDate 57054, anInboundCorrespondenceDeferraIDate 57058, a ClearingReasonCode 57062, anAmount 57066, a CurrencyCode 57070 and a CorrespondingTaxReturnID 57074.The @actionCode 57030 attribute has a cardinality of 1 57032 meaningthat for each instance of the FilingObligation 57026 entity there is one@actionCode 57030 attribute. The InboundCorrespondenceCategoryCode 57034attribute has a cardinality of 1 57036 meaning that for each instance ofthe FilingObligation 57026 entity there is oneInboundCorrespondenceCategoryCode 57034 attribute. The BillingPeriodID57038 attribute has a cardinality of 1 57040 meaning that for eachinstance of the FilingObligation 57026 entity there is oneBillingPeriodID 57038 attribute.

The BillingStartDate 57042 attribute has a cardinality of 1 57044meaning that for each instance of the FilingObligation 57026 entitythere is one BillingStartDate 57042 attribute. TheCorrespondenceStatusCode 57046 attribute has a cardinality of 0 . . . 157048 meaning that for each instance of the FilingObligation 57026entity there may be one CorrespondenceStatusCode 57046 attribute. TheInboundCorrespondenceDueDate 57050 attribute has a cardinality of 0 . .. 1 57052 meaning that for each instance of the FilingObligation 57026entity there may be one InboundCorrespondenceDueDate 57050 attribute.The InboundCorrespondenceReceivedDate in 57054 attribute has acardinality of 0 . . . 1 57056 meaning that for each instance of theFilingObligation 57026 entity there may be oneInboundCorrespondenceReceivedDate 57054 attribute. TheInboundCorrespondenceDeferraIDate 57058 attribute has a cardinality of 0. . . 1 57060 meaning that for each instance of the FilingObligation57026 entity there may be one InboundCorrespondenceDeferraIDate 57058attribute. The ClearingReasonCode 57062 attribute has a cardinality of 0. . . 1 57064 meaning that for each instance of the FilingObligation57026 entity there may be one ClearingReasonCode 57062 attribute. TheAmount 57066 attribute has a cardinality of 0 . . . 1 57068 meaning thatfor each instance of the FilingObligation 57026 entity there may be oneAmount 57066 attribute. The CurrencyCode 57070 attribute has acardinality of 0 . . . 1 57072 meaning that for each instance of theFilingObligation 57026 entity there may be one CurrencyCode 57070attribute. The CorrespondingTaxReturnID 57074 attribute has acardinality of 0 . . . 1 57076 meaning that for each instance of theFilingObligation 57026 entity there may be one CorrespondingTaxReturnID57074 attribute. The data types of the various packages, entities, andattributes are described with respect to FIG. 54.

In further detail, FIGS. 58-1 through 58-5 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPFilingObligationChangeConfirmationMessage_Sync 58000package. TheTaxObligationERPFilingObligationChangeConfirmationMessage_Sync 58000package includes aTaxObligationERPFilingObligationChangeConfirmationMessage_Sync 58002entity. TheTaxObligationERPFilingObligationChangeConfirmationMessage_Sync 58000package includes various packages, namely a MessageHeader 58004, aTaxObligation 58010 and a Log 58122.

The MessageHeader 58004 package includes a MessageHeader 58006 entity.The MessageHeader 58006 entity has a cardinality of 1 58008 meaning thatfor each instance of the MessageHeader 58004 package there is oneMessageHeader 58006 entity.

The TaxObligation 58010 package includes a TaxObligation 58012 entity.The TaxObligation 58010 package includes a FilingObligation 58048package.

The TaxObligation 58012 entity has a cardinality of 0 . . . 1 58014meaning that for each instance of the TaxObligation 58010 package theremay be one TaxObligation 58012 entity. The TaxObligation 58012 entityincludes various attributes, namely a TaxObligationID 58016, aTaxPayerPartyID 58020, a LevyTypeCode 58024, a LevyTypeName 58028, aStartBillingPeriodID 58032, a StartBillingPeriodName 58036, anEndBillingPeriodID 58040 and an EndBillingPeriodName 58044. TheTaxObligationID 58016 attribute has a cardinality of 1 58018 meaningthat for each instance of the TaxObligation 58012 entity there is oneTaxObligationID 58016 attribute. The TaxPayerPartyID 58020 attribute hasa cardinality of 1 58022 meaning that for each instance of theTaxObligation 58012 entity there is one TaxPayerPartyID 58020 attribute.

The LevyTypeCode 58024 attribute has a cardinality of 1 58026 meaningthat for each instance of the TaxObligation 58012 entity there is oneLevyTypeCode 58024 attribute. The LevyTypeName 58028 attribute has acardinality of 0 . . . 1 58030 meaning that for each instance of theTaxObligation 58012 entity there may be one LevyTypeName 58028attribute. The StartBillingPeriodID 58032 attribute has a cardinality of1 58034 meaning that for each instance of the TaxObligation 58012 entitythere is one StartBillingPeriodID 58032 attribute. TheStartBillingPeriodName 58036 attribute has a cardinality of 0 . . . 158038 meaning that for each instance of the TaxObligation 58012 entitythere may be one StartBillingPeriodName 58036 attribute. TheEndBillingPeriodID 58040 attribute has a cardinality of 0 . . . 1 58042meaning that for each instance of the TaxObligation 58012 entity theremay be one EndBillingPeriodID 58040 attribute. The EndBillingPeriodName58044 attribute has a cardinality of 0 . . . 1 58046 meaning that foreach instance of the TaxObligation 58012 entity there may be oneEndBillingPeriodName 58044 attribute.

The FilingObligation 58048 package includes a FilingObligation 58050entity. The FilingObligation 58050 entity has a cardinality of 0 . . . n58052 meaning that for each instance of the FilingObligation 58048package there may be one or more FilingObligation 58050 entities. TheFilingObligation 58050 entity includes various attributes, namely anInboundCorrespondenceCategoryCode 58054, anInboundCorrespondenceCategoryName 58058, a BillingPeriodID 58062, aBillingPeriodName 58066, a BillingStartDate 58070, aCorrespondenceStatusCode 58074, a CorrespondenceStatusName 58078, anInboundCorrespondenceDueDate 58082, an InboundCorrespondenceReceivedDate58086, an InboundCorrespondenceDeferraIDate 58090, a BillingEndDate58094, a ClearingReasonCode 58098, a ClearingReasonName 58102, an Amount58106, a CurrencyCode 58110, a CurrencyName 58114 and aCorrespondingTaxReturnID 58118. The InboundCorrespondenceCategoryCode58054 attribute has a cardinality of 1 58056 meaning that for eachinstance of the FilingObligation 58050 entity there is oneInboundCorrespondenceCategoryCode 58054 attribute.

The InboundCorrespondenceCategoryName 58058 attribute has a cardinalityof 0 . . . 1 58060 meaning that for each instance of theFilingObligation 58050 entity there may be oneInboundCorrespondenceCategoryName 58058 attribute. The BillingPeriodID58062 attribute has a cardinality of 1 58064 meaning that for eachinstance of the FilingObligation 58050 entity there is oneBillingPeriodID 58062 attribute. The BillingPeriodName 58066 attributehas a cardinality of 0 . . . 1 58068 meaning that for each instance ofthe FilingObligation 58050 entity there may be one BillingPeriodName58066 attribute. The BillingStartDate 58070 attribute has a cardinalityof 1 58072 meaning that for each instance of the FilingObligation 58050entity there is one BillingStartDate 58070 attribute. TheCorrespondenceStatusCode 58074 attribute has a cardinality of 0 . . . 158076 meaning that for each instance of the FilingObligation 58050entity there may be one CorrespondenceStatusCode 58074 attribute. TheCorrespondenceStatusName 58078 attribute has a cardinality of 0 . . . 158080 meaning that for each instance of the FilingObligation 58050entity there may be one CorrespondenceStatusName 58078 attribute.

The InboundCorrespondenceDueDate 58082 attribute has a cardinality of 158084 meaning that for each instance of the FilingObligation 58050entity there is one InboundCorrespondenceDueDate 58082 attribute. TheInboundCorrespondenceReceivedDate 58086 attribute has a cardinality of 0. . . 1 58088 meaning that for each instance of the FilingObligation58050 entity there may be one InboundCorrespondenceReceivedDate 58086attribute. The InboundCorrespondenceDeferraIDate 58090 attribute has acardinality of 0 . . . 1 58092 meaning that for each instance of theFilingObligation 58050 entity there may be oneInboundCorrespondenceDeferraIDate 58090 attribute. The BillingEndDate58094 attribute has a cardinality of 0 . . . 1 58096 meaning that foreach instance of the FilingObligation 58050 entity there may be oneBillingEndDate 58094 attribute. The ClearingReasonCode 58098 attributehas a cardinality of 0 . . . 1 58100 meaning that for each instance ofthe FilingObligation 58050 entity there may be one ClearingReasonCode58098 attribute.

The ClearingReasonName 58102 attribute has a cardinality of 0 . . . 158104 meaning that for each instance of the FilingObligation 58050entity there may be one ClearingReasonName 58102 attribute. The Amount58106 attribute has a cardinality of 1 58108 meaning that for eachinstance of the FilingObligation 58050 entity there is one Amount 58106attribute. The in CurrencyCode 58110 attribute has a cardinality of 158112 meaning that for each instance of the FilingObligation 58050entity there is one CurrencyCode 58110 attribute. The CurrencyName 58114attribute has a cardinality of 0 . . . 1 58116 meaning that for eachinstance of the FilingObligation 58050 entity there may be oneCurrencyName 58114 attribute. The CorrespondingTaxReturnID 58118attribute has a cardinality of 0 . . . 1 58120 meaning that for eachinstance of the FilingObligation 58050 entity there may be oneCorrespondingTaxReturnID 58118 attribute.

The Log 58122 package includes a Log 58124 entity. The Log 58124 entityhas a cardinality of 1 58126 meaning that for each instance of the Log58122 package there is one Log 58124 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 54.

In further detail, FIGS. 59-1 through 59-7 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPCheckQueryMessage_Sync 59000 package. TheTaxObligationERPCheckQueryMessage_Sync 59000 package includes aTaxObligationERPCheckQueryMessage_Sync 59002 entity. TheTaxObligationERPCheckQueryMessage_Sync 59000 package includes variouspackages, namely a MessageHeader 59004 and a TaxObligation 59010.

The MessageHeader 59004 package includes a MessageHeader 59006 entity.The MessageHeader 59006 entity has a cardinality of 1 59008 meaning thatfor each instance of the MessageHeader 59004 package there is oneMessageHeader 59006 entity.

The TaxObligation 59010 package includes a TaxObligation 59012 entity.The TaxObligation 59010 package includes various packages, namely aFilingRule 59060, a FilingExemption 59104, an InvoicingTerms 59126 and aRegistrationForm 59140.

The TaxObligation 59012 entity has a cardinality of 1 59014 meaning thatfor each instance of the TaxObligation 59010 package there is oneTaxObligation 59012 entity. The TaxObligation 59012 entity includesvarious attributes, namely a TaxObligationID 59016, a TaxPayerPartyID59020, a LevyTypeCode 59024, a StartBillingPeriodID 59028, anEndBillingPeriodID 59032, a TaxObjectID 59036, a ContractAccountID59040, a RegistrationStatusCode 59044, a ContactPartyID 59048, anElectronicFilingCode 59052 and an EmailReminderIndicator 59056. TheTaxObligationID 59016 attribute has a cardinality of 0 . . . 1 59018meaning that for each instance of the TaxObligation 59012 entity theremay be one TaxObligationID 59016 attribute. The TaxPayerPartyID 59020attribute has a cardinality of 0 . . . 1 59022 meaning that for eachinstance of the TaxObligation 59012 entity there may be oneTaxPayerPartyID 59020 attribute. The LevyTypeCode 59024 attribute has acardinality of 0 . . . 1 59026 meaning that for each instance of theTaxObligation 59012 entity there may be one LevyTypeCode 59024attribute.

The StartBillingPeriodID 59028 attribute has a cardinality of 0 . . . 159030 meaning that for each instance of the TaxObligation 59012 entitythere may be one StartBillingPeriodID 59028 attribute. TheEndBillingPeriodID 59032 attribute has a cardinality of 0 . . . 1 59034meaning that for each instance of the TaxObligation 59012 entity theremay be one EndBillingPeriodID 59032 attribute. The TaxObjectID 59036attribute has a cardinality of 0 . . . 1 59038 meaning that for eachinstance of the TaxObligation 59012 entity there may be one TaxObjectID59036 attribute. The ContractAccountID 59040 attribute has a cardinalityof 0 . . . 1 59042 meaning that for each instance of the TaxObligation59012 entity there may be one ContractAccountID 59040 attribute. TheRegistrationStatusCode 59044 attribute has a cardinality of 0 . . . 159046 meaning that for each instance of the TaxObligation 59012 entitythere may be one RegistrationStatusCode 59044 attribute. TheContactPartyID 59048 attribute has a cardinality of 0 . . . n 59050meaning that for each instance of the TaxObligation 59012 entity theremay be one or more ContactPartyID 59048 attributes. TheElectronicFilingCode 59052 attribute has a cardinality of 0 . . . 159054 meaning that for each instance of the TaxObligation 59012 entitythere may be one ElectronicFilingCode 59052 attribute. TheEmailReminderIndicator 59056 attribute has a cardinality of 0 . . . 159058 meaning that for each instance of the TaxObligation 59012 entitythere may be one EmailReminderIndicator 59056 attribute.

The FilingRule 59060 package includes a FilingRule 59062 entity. TheFilingRule 59060 package includes a Periodicity 59082 package.

The FilingRule 59062 entity has a cardinality of 0 . . . n 59064 meaningthat for each instance of the FilingRule 59060 package there may be oneor more FilingRule 59062 entities. The FilingRule 59062 entity includesvarious attributes, namely an InboundCorrespondenceCategoryCode 59066,an InboundCorrespondenceFirstBillingPeriodID 59070, aGenerationStatusCode 59074 and anInboundCorrespondenceLastBillingPeriodID 59078. TheInboundCorrespondenceCategoryCode 59066 attribute has a cardinality of 159068 meaning that for each instance of the FilingRule 59062 entitythere is one InboundCorrespondenceCategoryCode 59066 attribute. TheInboundCorrespondenceFirstBillingPeriodID 59070 attribute has acardinality of 1 59072 meaning that for each instance of the FilingRule59062 entity there is one InboundCorrespondenceFirstBillingPeriodID59070 attribute. The GenerationStatusCode 59074 attribute has acardinality of 0 . . . 1 59076 meaning that for each instance of theFilingRule 59062 entity there may be one GenerationStatusCode 59074attribute. The InboundCorrespondenceLastBillingPeriodID 59078 attributehas a cardinality of 0 . . . 1 59080 meaning that for each instance ofthe FilingRule 59062 entity there may be oneInboundCorrespondenceLastBillingPeriodID 59078 attribute.

The Periodicity 59082 package includes a DeviatingPeriod 59084 entity.The DeviatingPeriod 59084 entity has a cardinality of 0 . . . n 59086meaning that for each instance of the Periodicity 59082 package theremay be one or more DeviatingPeriod 59084 entities. The DeviatingPeriod59084 entity includes various attributes, namely a StartDate 59088, anEndDate 59092, a DueDate 59096 and a BillingPeriodID 59100. TheStartDate 59088 attribute has a cardinality of 1 59090 meaning that foreach instance of the DeviatingPeriod 59084 entity there is one StartDate59088 attribute. The EndDate 59092 attribute has a cardinality of 0 . .. 1 59094 meaning that for each instance of the DeviatingPeriod 59084entity there may be one EndDate 59092 attribute. The DueDate 59096attribute has a cardinality of 0 . . . 1 59098 meaning that for eachinstance of the DeviatingPeriod 59084 entity there may be one DueDate59096 attribute. The BillingPeriodID 59100 attribute has a cardinalityof 1 59102 meaning that for each instance of the DeviatingPeriod 59084entity there is one BillingPeriodID 59100 attribute.

The FilingExemption 59104 package includes a FilingExemption 59106entity. The FilingExemption 59106 entity has a cardinality of 0 . . . n59108 meaning that for each instance of the FilingExemption 59104package there may be one or more FilingExemption 59106 entities. TheFilingExemption 59106 entity includes various attributes, namely aStartDay 59110, a StartMonth 59114, an EndDay 59118 and an EndMonth59122. The StartDay 59110 attribute has a cardinality of 1 59112 meaningthat for each instance of the FilingExemption 59106 entity there is oneStartDay 59110 attribute. The StartMonth 59114 attribute has acardinality of 1 59116 meaning that for each instance of theFilingExemption 59106 entity there is one StartMonth 59114 attribute.The EndDay 59118 attribute has a cardinality of 1 59120 meaning that foreach instance of the FilingExemption 59106 entity there is one EndDay59118 attribute. The EndMonth 59122 attribute has a cardinality of 159124 meaning that for each instance of the FilingExemption 59106 entitythere is one EndMonth 59122 attribute.

The InvoicingTerms 59126 package includes an InvoicingTerms 59128entity. The InvoicingTerms 59128 entity has a cardinality of 0 . . . 159130 meaning that for each instance of the InvoicingTerms 59126 packagethere may be one InvoicingTerms 59128 entity. The InvoicingTerms 59128entity includes various attributes, namely aContractAccountContractReferenceID 59132 and a ChargePercent 59136. TheContractAccountContractReferenceID 59132 attribute has a cardinality of0 . . . 1 59134 meaning that for each instance of the InvoicingTerms59128 entity there may be one ContractAccountContractReferenceID 59132attribute. The ChargePercent 59136 attribute has a cardinality of 159138 meaning that for each instance of the InvoicingTerms 59128 entitythere is one ChargePercent 59136 attribute.

The RegistrationForm 59140 package includes a RegistrationForm 59142entity. The RegistrationForm 59140 package includes a PropertyValuation59158 package.

The RegistrationForm 59142 entity has a cardinality of 0 . . . n 59144meaning that for each instance of the RegistrationForm 59140 packagethere may be one or more RegistrationForm 59142 entities. TheRegistrationForm 59142 entity includes various attributes, namely aFormTemplateID 59146, a FormVersionID 59150 and a FormStatusCode 59154.The FormTemplateID 59146 attribute has a cardinality of 1 59148 meaningthat for each instance of the RegistrationForm 59142 entity there is oneFormTemplateID 59146 attribute. The FormVersionID 59150 attribute has acardinality of 1 59152 meaning that for each instance of theRegistrationForm 59142 entity there is one FormVersionID 59150attribute. The FormStatusCode 59154 attribute has a cardinality of 0 . .. 1 59156 meaning that for each instance of the RegistrationForm 59142entity there may be one FormStatusCode 59154 attribute.

The PropertyValuation 59158 package includes a PropertyValuation 59160entity. The PropertyValuation 59160 entity has a cardinality of 1 . . .n 59162 meaning that for each instance of the PropertyValuation 59158package there are one or more PropertyValuation 59160 entities. ThePropertyValuation 59160 entity includes a PropertyValuation 59164attribute. The PropertyValuation 59164 attribute has a cardinality of 0. . . 1 59166 meaning that for each instance of the PropertyValuation59160 entity there may be one PropertyValuation 59164 attribute.

The data types of the various packages, entities, and attributes aredescribed with respect to FIG. 54.

In further detail, FIGS. 60-1 through 60-9 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPCheckResponseMessage 60000 package. TheTaxObligationERPCheckResponseMessage 60000 package includes aTaxObligationERPCheckResponseMessage 60002 entity. TheTaxObligationERPCheckResponseMessage 60000 package includes variouspackages, namely a MessageHeader 60004, a TaxObligation 60010 and a Log60220.

The MessageHeader 60004 package includes a MessageHeader 60006 entity.The MessageHeader 60006 entity has a cardinality of 1 60008 meaning thatfor each instance of the MessageHeader 60004 package there is oneMessageHeader 60006 entity.

The TaxObligation 60010 package includes a TaxObligation 60012 entity.The TaxObligation 60010 package includes various packages, namely aFilingRule 60080, a FilingExemption 60156, an InvoicingTerms 60178 and aRegistrationForm 60192.

The TaxObligation 60012 entity has a cardinality of 0 . . . 1 60014meaning that for each instance of the TaxObligation 60010 package theremay be one TaxObligation 60012 entity. The TaxObligation 60012 entityincludes various attributes, namely a TaxObligationID 60016, aTaxPayerPartyID 60020, a LevyTypeCode 60024, a LevyTypeName 60028, aStartBillingPeriodID 60032, a StartBillingPeriodName 60036, anEndBillingPeriodID 60040, an EndBillingPeriodName 60044, aValidityStartDate 60048, a ValidityEndDate 60052, a ContractAccountID60056, a RegistrationStatusCode 60060, a RegistrationStatusName 60064, aContactPartyID 60068, an ElectronicFilingCode 60072 and anEmailReminderIndicator 60076. The TaxObligationID 60016 attribute has acardinality of 0 . . . 1 60018 meaning that for each instance of theTaxObligation 60012 entity there may be one TaxObligationID 60016attribute. The TaxPayerPartyID 60020 attribute has a cardinality of 160022 meaning that for each instance of the TaxObligation 60012 entitythere is one TaxPayerPartyID 60020 attribute.

The LevyTypeCode 60024 attribute has a cardinality of 1 60026 meaningthat for each instance of the TaxObligation 60012 entity there is oneLevyTypeCode 60024 attribute. The LevyTypeName 60028 attribute has acardinality of 0 . . . 1 60030 meaning that for each instance of theTaxObligation 60012 entity there may be one LevyTypeName 60028attribute. The StartBillingPeriodID 60032 attribute has a cardinality of1 60034 meaning that for each instance of the TaxObligation 60012 entitythere is one StartBillingPeriodID 60032 attribute. TheStartBillingPeriodName 60036 attribute has a cardinality of 0 . . . 160038 meaning that for each instance of the TaxObligation 60012 entitythere may be one StartBillingPeriodName 60036 attribute. TheEndBillingPeriodID 60040 attribute has a cardinality of 0 . . . 1 60042meaning that for each instance of the TaxObligation 60012 entity theremay be one EndBillingPeriodID 60040 attribute. The EndBillingPeriodName60044 attribute has a cardinality of 0 . . . 1 60046 meaning that foreach instance of the TaxObligation 60012 entity there may be oneEndBillingPeriodName 60044 attribute.

The ValidityStartDate 60048 attribute has a cardinality of 0 . . . 160050 meaning that for each instance of the TaxObligation 60012 entitythere may be one ValidityStartDate 60048 attribute. The ValidityEndDate60052 attribute has a cardinality of 0 . . . 1 60054 meaning that foreach instance of the TaxObligation 60012 entity there may be oneValidityEndDate 60052 attribute. The ContractAccountID 60056 attributehas a cardinality of 1 60058 meaning that for each instance of theTaxObligation 60012 entity there is one ContractAccountID 60056attribute. The RegistrationStatusCode 60060 attribute has a cardinalityof 0 . . . 1 60062 meaning that for each instance of the TaxObligation60012 entity there may be one RegistrationStatusCode 60060 attribute.The RegistrationStatusName 60064 attribute has a cardinality of 0 . . .1 60066 meaning that for each instance of the TaxObligation 60012 entitythere may be one RegistrationStatusName 60064 attribute. TheContactPartyID 60068 attribute has a cardinality of 0 . . . n 60070meaning that for each instance of the TaxObligation 60012 entity theremay be one or more ContactPartyID 60068 attributes. TheElectronicFilingCode 60072 attribute has a cardinality of 0 . . . 160074 meaning that for each instance of the TaxObligation 60012 entitythere may be one ElectronicFilingCode 60072 attribute. TheEmailReminderIndicator 60076 attribute has a cardinality of 1 60078meaning that for each instance of the TaxObligation 60012 entity thereis one EmailReminderIndicator 60076 attribute.

The FilingRule 60080 package includes a FilingRule 60082 entity. TheFilingRule 60080 package includes a Periodicity 60106 package.

The FilingRule 60082 entity has a cardinality of 0 . . . n 60084 meaningthat for each instance of the FilingRule 60080 package there may be oneor more FilingRule 60082 entities. The FilingRule 60082 entity includesvarious attributes, namely an InboundCorrespondenceCategoryCode 60086,an InboundCorrespondenceFirstBillingPeriodID 60090, aGenerationStatusCode 60094, a GenerationStatusName 60098 and anInboundCorrespondenceLastBillingPeriodID 60102. TheInboundCorrespondenceCategoryCode 60086 attribute has a cardinality of 160088 meaning that for each instance of the FilingRule 60082 entitythere is one InboundCorrespondenceCategoryCode 60086 attribute. TheInboundCorrespondenceFirstBillingPeriodID 60090 attribute has acardinality of 1 60092 meaning that for each instance of the FilingRule60082 entity there is one InboundCorrespondenceFirstBillingPeriodID60090 attribute. The GenerationStatusCode 60094 attribute has acardinality of 1 60096 meaning that for each instance of the FilingRule60082 entity there is one GenerationStatusCode 60094 attribute. TheGenerationStatusName 60098 attribute has a cardinality of 0 . . . 160100 meaning that for each instance of the FilingRule 60082 entitythere may be one GenerationStatusName 60098 attribute. TheInboundCorrespondenceLastBillingPeriodID 60102 attribute has acardinality of 0 . . . 1 60104 meaning that for each instance of theFilingRule 60082 entity there may be oneInboundCorrespondenceLastBillingPeriodID 60102 attribute.

The Periodicity 60106 package includes various entities, namely aDeviatingPeriod 60108 and a StandardPeriod 60132. The DeviatingPeriod60108 entity has a cardinality of 0 . . . n 60110 meaning that for eachinstance of the Periodicity 60106 package there may be one or moreDeviatingPeriod 60108 entities. The DeviatingPeriod 60108 entityincludes various attributes, namely a StartDate 60112, an EndDate 60116,a DueDate 60120, a BillingPeriodID 60124 and a BillingPeriodName 60128.The StartDate 60112 attribute has a cardinality of 1 60114 meaning thatfor each instance of the DeviatingPeriod 60108 entity there is oneStartDate 60112 attribute. The EndDate 60116 attribute has a cardinalityof 1 60118 meaning that for each instance of the DeviatingPeriod 60108entity there is one EndDate 60116 attribute. The DueDate 60120 attributehas a cardinality of 0 . . . 1 60122 meaning that for each instance ofthe DeviatingPeriod 60108 entity there may be one DueDate 60120attribute. The BillingPeriodID 60124 attribute has a cardinality of 160126 meaning that for each instance of the DeviatingPeriod 60108 entitythere is one BillingPeriodID 60124 attribute. The BillingPeriodName60128 attribute has a cardinality of 0 . . . 1 60130 meaning that foreach instance of the DeviatingPeriod 60108 entity there may be oneBillingPeriodName 60128 attribute.

The StandardPeriod 60132 entity has a cardinality of 0 . . . n 60134meaning that for each instance of the Periodicity 60106 package theremay be one or more StandardPeriod 60132 entities. The StandardPeriod60132 entity includes various attributes, namely a StartDate 60136, anEndDate 60140, a DueDate 60144, a BillingPeriodID 60148 and aBillingPeriodName 60152. The StartDate 60136 attribute has a cardinalityof 1 60138 meaning that for each instance of the StandardPeriod 60132entity there is one StartDate 60136 attribute. The EndDate 60140attribute has a cardinality of 1 60142 meaning that for each instance ofthe StandardPeriod 60132 entity there is one EndDate 60140 attribute.The DueDate 60144 attribute has a cardinality of 0 . . . 1 60146 meaningthat for each instance of the StandardPeriod 60132 entity there may beone DueDate 60144 attribute. The BillingPeriodID 60148 attribute has acardinality of 1 60150 meaning that for each instance of theStandardPeriod 60132 entity there is one BillingPeriodID 60148attribute. The BillingPeriodName 60152 attribute has a cardinality of 0. . . 1 60154 meaning that for each instance of the StandardPeriod 60132entity there may be one BillingPeriodName 60152 attribute.

The FilingExemption 60156 package includes a FilingExemption 60158entity. The FilingExemption 60158 entity has a cardinality of 0 . . . n60160 meaning that for each instance of the FilingExemption 60156package there may be one or more FilingExemption 60158 entities. TheFilingExemption 60158 entity includes various attributes, namely aStartDay 60162, a StartMonth 60166, an EndDay 60170 and an EndMonth60174. The StartDay 60162 attribute has a cardinality of 1 60164 meaningthat for each instance of the FilingExemption 60158 entity there is oneStartDay 60162 attribute. The StartMonth 60166 attribute has acardinality of 1 60168 meaning that for each instance of theFilingExemption 60158 entity there is one StartMonth 60166 attribute.The EndDay 60170 attribute has a cardinality of 1 60172 meaning that foreach instance of the FilingExemption 60158 entity there is one EndDay60170 attribute. The EndMonth 60174 attribute has a cardinality of 160176 meaning that for each instance of the FilingExemption 60158 entitythere is one EndMonth 60174 attribute. The InvoicingTerms 60178 packageincludes an InvoicingTerms 60180 entity. The InvoicingTerms 60180 entityhas a cardinality of 1 60182 meaning that for each instance of theInvoicingTerms 60178 package there is one InvoicingTerms 60180 entity.The InvoicingTerms 60180 entity includes various attributes, namely aContractAccountContractReferenceID 60184 and a ChargePercent 60188. TheContractAccountContractReferenceID 60184 attribute has a cardinality of0 . . . 1 60186 meaning that for each instance of the InvoicingTerms60180 entity there may be one ContractAccountContractReferenceID 60184attribute. The ChargePercent 60188 attribute has a cardinality of 160190 meaning that for each instance of the InvoicingTerms 60180 entitythere is one ChargePercent 60188 attribute.

The RegistrationForm 60192 package includes a RegistrationForm 60194entity. The RegistrationForm 60192 package includes a PropertyValuation60210 package.

The RegistrationForm 60194 entity has a cardinality of 0 . . . n 60196meaning that for each instance of the RegistrationForm 60192 packagethere may be one or more RegistrationForm 60194 entities. TheRegistrationForm 60194 entity includes various attributes, namely aFormTemplateID 60198, a FormVersionID 60202 and a FormStatusCode 60206.The FormTemplateID 60198 attribute has a cardinality of 1 60200 meaningthat for each instance of the RegistrationForm 60194 entity there is oneFormTemplateID 60198 attribute. The FormVersionID 60202 attribute has acardinality of 1 60204 meaning that for each instance of theRegistrationForm 60194 entity there is one FormVersionID 60202attribute. The FormStatusCode 60206 attribute has a cardinality of 0 . .. 1 60208 meaning that for each instance of the RegistrationForm 60194entity there may be one FormStatusCode 60206 attribute.

The PropertyValuation 60210 package includes a PropertyValuation 60212entity. The PropertyValuation 60212 entity has a cardinality of 1 . . .n 60214 meaning that for each instance of the PropertyValuation 60210package there are one or more PropertyValuation 60212 entities. ThePropertyValuation 60212 entity includes a PropertyValuation 60216attribute. The PropertyValuation 60216 attribute has a cardinality of 0. . . 1 60218 meaning that for each instance of the PropertyValuation60212 entity there may be one PropertyValuation 60216 attribute.

The Log 60220 package includes a Log 60222 entity. The Log 60222 entityhas a cardinality of 1 60224 meaning that for each instance of the Log60220 package there is one Log 60222 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 54.

In further detail, FIGS. 61-1 through 61-3 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPFilingObligationCheckQueryMessage_Sync 61000 package.The TaxObligationERPFilingObligationCheckQueryMessage_Sync 61000 packageincludes a TaxObligationERPFilingObligationCheckQueryMessage_Sync 61002entity. The TaxObligationERPFilingObligationCheckQueryMessage_Sync 61000package includes various packages, namely a MessageHeader 61004 and aTaxObligation 61010.

The MessageHeader 61004 package includes a MessageHeader 61006 entity.The MessageHeader 61006 entity has a cardinality of 1 61008 meaning thatfor each instance of the MessageHeader 61004 package there is oneMessageHeader 61006 entity.

The TaxObligation 61010 package includes a TaxObligation 61012 entity.The TaxObligation 61010 package includes a FilingObligation 61020package.

The TaxObligation 61012 entity has a cardinality of 1 61014 meaning thatfor each instance of the TaxObligation 61010 package there is oneTaxObligation 61012 entity. The TaxObligation 61012 entity includes aTaxObligationID 61016 attribute. The TaxObligationID 61016 attribute hasa cardinality of 1 61018 meaning that for each instance of theTaxObligation 61012 entity there is one TaxObligationID 61016 attribute.

The FilingObligation 61020 package includes a FilingObligation 61022entity. The FilingObligation 61022 entity has a cardinality of 0 . . . n61024 meaning that for each instance of the FilingObligation 61020package there may be one or more FilingObligation 61022 entities. TheFilingObligation 61022 entity includes various attributes, namely anInboundCorrespondenceCategoryCode 61026, a BillingPeriodID 61030, aBillingStartDate 61034, a Correspondence StatusCode 61038, anInboundCorrespondenceDueDate 61042, an InboundCorrespondenceReceivedDate61046, an InboundCorrespondenceDeferraIDate 61050, a ClearingReasonCode61054, an Amount 61058, a CurrencyCode 61062 and aCorrespondingTaxReturnID 61066. The InboundCorrespondenceCategoryCode61026 attribute has a cardinality of 1 61028 meaning that for eachinstance of the FilingObligation 61022 entity there is oneInboundCorrespondenceCategoryCode 61026 attribute. The BillingPeriodID61030 attribute has a cardinality of 1 61032 meaning that for eachinstance of the FilingObligation 61022 entity there is oneBillingPeriodID 61030 attribute.

The BillingStartDate 61034 attribute has a cardinality of 1 61036meaning that for each instance of the FilingObligation 61022 entitythere is one BillingStartDate 61034 attribute. TheCorrespondenceStatusCode 61038 attribute has a cardinality of 0 . . . 161040 meaning that for each instance of the FilingObligation 61022entity there may be one CorrespondenceStatusCode 61038 attribute. TheInboundCorrespondenceDueDate 61042 attribute has a cardinality of 0 . .. 1 61044 meaning that for each instance of the FilingObligation 61022entity there may be one InboundCorrespondenceDueDate 61042 attribute.The InboundCorrespondenceReceivedDate in 61046 attribute has acardinality of 0 . . . 1 61048 meaning that for each instance of theFilingObligation 61022 entity there may be oneInboundCorrespondenceReceivedDate 61046 attribute. TheInboundCorrespondenceDeferraIDate 61050 attribute has a cardinality of 0. . . 1 61052 meaning that for each instance of the FilingObligation61022 entity there may be one InboundCorrespondenceDeferraIDate 61050attribute. The ClearingReasonCode 61054 attribute has a cardinality of 0. . . 1 61056 meaning that for each instance of the FilingObligation61022 entity there may be one ClearingReasonCode 61054 attribute. TheAmount 61058 attribute has a cardinality of 0 . . . 1 61060 meaning thatfor each instance of the FilingObligation 61022 entity there may be oneAmount 61058 attribute. The CurrencyCode 61062 attribute has acardinality of 0 . . . 1 61064 meaning that for each instance of theFilingObligation 61022 entity there may be one CurrencyCode 61062attribute. The CorrespondingTaxReturnID 61066 attribute has acardinality of 0 . . . 1 61068 meaning that for each instance of theFilingObligation 61022 entity there may be one CorrespondingTaxReturnID61066 attribute. The data types of the various packages, entities, andattributes are described with respect to FIG. 54.

In further detail, FIGS. 62-1 through 62-5 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPFilingObligationCheckResponseMessage_Sync 62000 package.The TaxObligationERPFilingObligationCheckResponseMessage_Sync 62000package includes aTaxObligationERPFilingObligationCheckResponseMessage_Sync 62002 entity.The TaxObligationERPFilingObligationCheckResponseMessage_Sync 62000package includes various packages, namely a MessageHeader 62004, aTaxObligation 62010 and a Log 62122.

The MessageHeader 62004 package includes a MessageHeader 62006 entity.The MessageHeader 62006 entity has a cardinality of 1 62008 meaning thatfor each instance of the MessageHeader 62004 package there is oneMessageHeader 62006 entity.

The TaxObligation 62010 package includes a TaxObligation 62012 entity.The TaxObligation 62010 package includes a FilingObligation 62048package.

The TaxObligation 62012 entity has a cardinality of 0 . . . 1 62014meaning that for each instance of the TaxObligation 62010 package theremay be one TaxObligation 62012 entity. The TaxObligation 62012 entityincludes various attributes, namely a TaxObligationID 62016, aTaxPayerPartyID 62020, a LevyTypeCode 62024, a LevyTypeName 62028, aStartBillingPeriodID 62032, a StartBillingPeriodName 62036, anEndBillingPeriodID 62040 and an EndBillingPeriodName 62044. TheTaxObligationID 62016 attribute has a cardinality of 1 62018 meaningthat for each instance of the TaxObligation 62012 entity there is oneTaxObligationID 62016 attribute. The TaxPayerPartyID 62020 attribute hasa cardinality of 1 62022 meaning that for each instance of theTaxObligation 62012 entity there is one TaxPayerPartyID 62020 attribute.The LevyTypeCode 62024 attribute has a cardinality of 1 62026 meaningthat for each instance of the TaxObligation 62012 entity there is oneLevyTypeCode 62024 attribute. The LevyTypeName 62028 attribute has acardinality of 0 . . . 1 62030 meaning that for each instance of theTaxObligation 62012 entity there may be one LevyTypeName 62028attribute. The StartBillingPeriodID 62032 attribute has a cardinality of1 62034 meaning that for each instance of the TaxObligation 62012 entitythere is one StartBillingPeriodID 62032 attribute. TheStartBillingPeriodName 62036 attribute has a cardinality of 0 . . . 162038 meaning that for each instance of the TaxObligation 62012 entitythere may be one StartBillingPeriodName 62036 attribute. TheEndBillingPeriodID 62040 attribute has a cardinality of 0 . . . 1 62042meaning that for each instance of the TaxObligation 62012 entity theremay be one EndBillingPeriodID 62040 attribute. The EndBillingPeriodName62044 attribute has a cardinality of 0 . . . 1 62046 meaning that foreach instance of the TaxObligation 62012 entity there may be oneEndBillingPeriodName 62044 attribute.

The FilingObligation 62048 package includes a FilingObligation 62050entity. The FilingObligation 62050 entity has a cardinality of 0 . . . n62052 meaning that for each instance of the FilingObligation 62048package there may be one or more FilingObligation 62050 entities. TheFilingObligation 62050 entity includes various attributes, namely anInboundCorrespondenceCategoryCode 62054, anInboundCorrespondenceCategoryName 62058, a BillingPeriodID 62062, aBillingPeriodName 62066, a BillingStartDate 62070, aCorrespondenceStatusCode 62074, a CorrespondenceStatusName 62078, anInboundCorrespondenceDueDate 62082, an InboundCorrespondenceReceivedDate62086, an InboundCorrespondenceDeferraIDate 62090, a BillingEndDate62094, a ClearingReasonCode 62098, a ClearingReasonName 62102, an Amount62106, a CurrencyCode 62110, a CurrencyName 62114 and aCorrespondingTaxReturnID 62118. The InboundCorrespondenceCategoryCode62054 attribute has a cardinality of 1 62056 meaning that for eachinstance of the FilingObligation 62050 entity there is oneInboundCorrespondenceCategoryCode 62054 attribute.

The InboundCorrespondenceCategoryName 62058 attribute has a cardinalityof 0 . . . 1 62060 meaning that for each instance of theFilingObligation 62050 entity there may be oneInboundCorrespondenceCategoryName 62058 attribute. The BillingPeriodID62062 attribute has a cardinality of 1 62064 meaning that for eachinstance of the FilingObligation 62050 entity there is oneBillingPeriodID 62062 attribute. The BillingPeriodName 62066 attributehas a cardinality of 0 . . . 1 62068 meaning that for each instance ofthe FilingObligation 62050 entity there may be one BillingPeriodName62066 attribute. The BillingStartDate 62070 attribute has a cardinalityof 1 62072 meaning that for each instance of the FilingObligation 62050entity there is one BillingStartDate 62070 attribute. TheCorrespondenceStatusCode 62074 attribute has a cardinality of 0 . . . 162076 meaning that for each instance of the FilingObligation 62050entity there may be one CorrespondenceStatusCode 62074 attribute. TheCorrespondenceStatusName 62078 attribute has a cardinality of 0 . . . 162080 meaning that for each instance of the FilingObligation 62050entity there may be one CorrespondenceStatusName 62078 attribute. TheInboundCorrespondenceDueDate 62082 attribute has a cardinality of 162084 meaning that for each instance of the FilingObligation 62050entity there is one InboundCorrespondenceDueDate 62082 attribute.

The InboundCorrespondenceReceivedDate 62086 attribute has a cardinalityof 0 . . . 1 62088 meaning that for each instance of theFilingObligation 62050 entity there may be oneInboundCorrespondenceReceivedDate 62086 attribute. TheInboundCorrespondenceDeferraIDate 62090 attribute has a cardinality of 0. . . 1 62092 meaning that for each instance of the FilingObligation62050 entity there may be one InboundCorrespondenceDeferraIDate 62090attribute. The BillingEndDate 62094 attribute has a cardinality of 0 . .. 1 62096 meaning that for each instance of the FilingObligation 62050entity there may be one BillingEndDate 62094 attribute. TheClearingReasonCode 62098 attribute has a cardinality of 0 . . . 1 62100meaning that for each instance of the FilingObligation 62050 entitythere may be one ClearingReasonCode 62098 attribute. TheClearingReasonName 62102 attribute has a cardinality of 0 . . . 1 62104meaning that for each instance of the FilingObligation 62050 entitythere may be one ClearingReasonName 62102 attribute. The Amount 62106attribute has a cardinality of 1 62108 meaning that for each instance ofthe FilingObligation 62050 entity there is one Amount 62106 attribute.The CurrencyCode 62110 attribute has a cardinality of 1 62112 meaningthat for each instance of the FilingObligation 62050 entity there is oneCurrencyCode 62110 attribute. The CurrencyName 62114 attribute has acardinality of 0 . . . 1 62116 meaning that for each instance of theFilingObligation 62050 entity there may be one CurrencyName 62114attribute. The CorrespondingTaxReturnID 62118 attribute has acardinality of 0 . . . 1 62120 meaning that for each instance of theFilingObligation 62050 entity there may be one CorrespondingTaxReturnID62118 attribute.

The Log 62122 package includes a Log 62124 entity. The Log 62124 entityhas a cardinality of 1 62126 meaning that for each instance of the Log62122 package there is one Log 62124 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 54.

In further detail, FIGS. 63-1 through 63-6 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPCreateRequestMessage_Sync 63000 package. TheTaxObligationERPCreateRequestMessage_Sync 63000 package includes aTaxObligationERPCreateRequestMessage_Sync 63002 entity. TheTaxObligationERPCreateRequestMessage_Sync 63000 package includes variouspackages, namely a MessageHeader 63004 and a TaxObligation 63010.

The MessageHeader 63004 package includes a MessageHeader 63006 entity.The MessageHeader 63006 entity has a cardinality of 1 63008 meaning thatfor each instance of the MessageHeader 63004 package there is oneMessageHeader 63006 entity.

The TaxObligation 63010 package includes a TaxObligation 63012 entity.The TaxObligation 63010 package includes various packages, namely aFilingRule 63052, a FilingExemption 63096, an InvoicingTerms 63118 and aRegistrationForm 63132.

The TaxObligation 63012 entity has a cardinality of 1 63014 meaning thatfor each instance of the TaxObligation 63010 package there is oneTaxObligation 63012 entity. The TaxObligation 63012 entity includesvarious attributes, namely a TaxPayerPartyID 63016, a LevyTypeCode63020, a StartBillingPeriodID 63024, an EndBillingPeriodID 63028, aTaxObjectID 63032, a ContractAccountID 63036, a ContactPartyID 63040, anElectronicFilingCode 63044 and an EmailReminderIndicator 63048. TheTaxPayerPartyID 63016 attribute has a cardinality of 1 63018 meaningthat for each instance of the TaxObligation 63012 entity there is oneTaxPayerPartyID 63016 attribute. The LevyTypeCode 63020 attribute has acardinality of 1 63022 meaning that for each instance of theTaxObligation 63012 entity there is one LevyTypeCode 63020 attribute.The StartBillingPeriodID 63024 attribute has a cardinality of 1 63026meaning that for each instance of the TaxObligation 63012 entity thereis one StartBillingPeriodID 63024 attribute. The EndBillingPeriodID63028 attribute has a cardinality of 0 . . . 1 63030 meaning that foreach instance of the TaxObligation 63012 entity there may be oneEndBillingPeriodID 63028 attribute. The TaxObjectID 63032 attribute hasa cardinality of 0 . . . 1 63034 meaning that for each instance of theTaxObligation 63012 entity there may be one TaxObjectID 63032 attribute.The ContractAccountID 63036 attribute has a cardinality of 0 . . . 163038 meaning that for each instance of the TaxObligation 63012 entitythere may be one ContractAccountID 63036 attribute. The ContactPartyID63040 attribute has a cardinality of 0 . . . n 63042 meaning that foreach instance of the TaxObligation 63012 entity there may be one or moreContactPartyID 63040 attributes. The ElectronicFilingCode 63044attribute has a cardinality of 0 . . . 1 63046 meaning that for eachinstance of the TaxObligation 63012 entity there may be oneElectronicFilingCode 63044 attribute. The EmailReminderIndicator 63048attribute has a cardinality of 0 . . . 1 63050 meaning that for eachinstance of the TaxObligation 63012 entity there may be oneEmailReminderIndicator 63048 attribute.

The FilingRule 63052 package includes a FilingRule 63054 entity. TheFilingRule 63052 package includes a Periodicity 63074 package.

The FilingRule 63054 entity has a cardinality of 0 . . . n 63056 meaningthat for each instance of the FilingRule 63052 package there may be oneor more FilingRule 63054 entities. The FilingRule 63054 entity includesvarious attributes, namely an InboundCorrespondenceCategoryCode 63058,an InboundCorrespondenceFirstBillingPeriodID 63062, aGenerationStatusCode 63066 and anInboundCorrespondenceLastBillingPeriodID 63070. TheInboundCorrespondenceCategoryCode 63058 attribute has a cardinality of 163060 meaning that for each instance of the FilingRule 63054 entitythere is one InboundCorrespondenceCategoryCode 63058 attribute. TheInboundCorrespondenceFirstBillingPeriodID 63062 attribute has acardinality of 1 63064 meaning that for each instance of the FilingRule63054 entity there is one InboundCorrespondenceFirstBillingPeriodID63062 attribute. The GenerationStatusCode 63066 attribute has acardinality of 1 63068 meaning that for each instance of the FilingRule63054 entity there is one GenerationStatusCode 63066 attribute. TheInboundCorrespondenceLastBillingPeriodID 63070 attribute has acardinality of 0 . . . 1 63072 meaning that for each instance of theFilingRule 63054 entity there may be oneInboundCorrespondenceLastBillingPeriodID 63070 attribute.

The Periodicity 63074 package includes a DeviatingPeriod 63076 entity.The DeviatingPeriod 63076 entity has a cardinality of 0 . . . n 63078meaning that for each instance of the Periodicity 63074 package theremay be one or more DeviatingPeriod 63076 entities. The DeviatingPeriod63076 entity includes various attributes, namely a StartDate 63080, anEndDate 63084, a DueDate 63088 and a BillingPeriodID 63092. TheStartDate 63080 attribute has a cardinality of 1 63082 meaning that foreach instance of the DeviatingPeriod 63076 entity there is one StartDate63080 attribute. The EndDate 63084 attribute has a cardinality of 0 . .. 1 63086 meaning that for each instance of the DeviatingPeriod 63076entity there may be one EndDate 63084 attribute. The DueDate 63088attribute has a cardinality of 0 . . . 1 63090 meaning that for eachinstance of the DeviatingPeriod 63076 entity there may be one DueDate63088 attribute. The BillingPeriodID 63092 attribute has a cardinalityof 1 63094 meaning that for each instance of the DeviatingPeriod 63076entity there is one BillingPeriodID 63092 attribute.

The FilingExemption 63096 package includes a FilingExemption 63098entity. The FilingExemption 63098 entity has a cardinality of 0 . . . n63100 meaning that for each instance of the FilingExemption 63096package there may be one or more FilingExemption 63098 entities. TheFilingExemption 63098 entity includes various attributes, namely aStartDay 63102, a StartMonth 63106, an EndDay 63110 and an EndMonth63114. The StartDay 63102 attribute has a cardinality of 1 63104 meaningthat for each instance of the FilingExemption 63098 entity there is oneStartDay 63102 attribute. The StartMonth 63106 attribute has acardinality of 1 63108 meaning that for each instance of theFilingExemption 63098 entity there is one StartMonth 63106 attribute.The EndDay 63110 attribute has a cardinality of 1 63112 meaning that foreach instance of the FilingExemption 63098 entity there is one EndDay63110 attribute. The EndMonth 63114 attribute has a cardinality of 163116 meaning that for each instance of the FilingExemption 63098 entitythere is one EndMonth 63114 attribute.

The InvoicingTerms 63118 package includes an InvoicingTerms 63120entity. The InvoicingTerms 63120 entity has a cardinality of 1 63122meaning that for each instance of the InvoicingTerms 63118 package thereis one InvoicingTerms 63120 entity. The InvoicingTerms 63120 entityincludes various attributes, namely a ContractAccountContractReferenceID63124 and a ChargePercent 63128. The ContractAccountContractReferenceID63124 attribute has a cardinality of 0 . . . 1 63126 meaning that foreach instance of the InvoicingTerms 63120 entity there may be oneContractAccountContractReferenceID 63124 attribute. The ChargePercent63128 attribute has a cardinality of 1 63130 meaning that for eachinstance of the InvoicingTerms 63120 entity there is one ChargePercent63128 attribute.

The RegistrationForm 63132 package includes a RegistrationForm 63134entity. The RegistrationForm 63132 package includes a PropertyValuation63150 package. The RegistrationForm 63134 entity has a cardinality of 0. . . n 63136 meaning that for each instance of the RegistrationForm63132 package there may be one or more RegistrationForm 63134 entities.The RegistrationForm 63134 entity includes various attributes, namely aFormTemplateID 63138, a FormVersionID 63142 and a FormStatusCode 63146.The FormTemplateID 63138 attribute has a cardinality of 1 63140 meaningthat for each instance of the RegistrationForm 63134 entity there is oneFormTemplateID 63138 attribute. The FormVersionID 63142 attribute has acardinality of 1 63144 meaning that for each instance of theRegistrationForm 63134 entity there is one FormVersionID 63142attribute. The FormStatusCode 63146 attribute has a cardinality of 0 . .. 1 63148 meaning that for each instance of the RegistrationForm 63134entity there may be one FormStatusCode 63146 attribute.

The PropertyValuation 63150 package includes a PropertyValuation 63152entity. The PropertyValuation 63152 entity has a cardinality of 1 . . .n 63154 meaning that for each instance of the PropertyValuation 63150package there are one or more PropertyValuation 63152 entities. ThePropertyValuation 63152 entity includes a PropertyValuation 63156attribute. The PropertyValuation 63156 attribute has a cardinality of 0. . . 1 63158 meaning that for each instance of the PropertyValuation63152 entity there may be one PropertyValuation 63156 attribute. Thedata types of the various packages, entities, and attributes aredescribed with respect to FIG. 54.

In further detail, FIGS. 64-1 through 64-9 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPCreateConfirmationMessage_Sync 64000 package. TheTaxObligationERPCreateConfirmationMessage_Sync 64000 package includes aTaxObligationERPCreateConfirmationMessage_Sync 64002 entity. TheTaxObligationERPCreateConfirmationMessage_Sync 64000 package includesvarious packages, namely a MessageHeader 64004, a TaxObligation 64010and a Log 64220.

The MessageHeader 64004 package includes a MessageHeader 64006 entity.The MessageHeader 64006 entity has a cardinality of 1 64008 meaning thatfor each instance of the MessageHeader 64004 package there is oneMessageHeader 64006 entity.

The TaxObligation 64010 package includes a TaxObligation 64012 entity.The TaxObligation 64010 package includes various packages, namely aFilingRule 64080, a FilingExemption 64156, an InvoicingTerms 64178 and aRegistrationForm 64192.

The TaxObligation 64012 entity has a cardinality of 1 64014 meaning thatfor each instance of the TaxObligation 64010 package there is oneTaxObligation 64012 entity. The TaxObligation 64012 entity includesvarious attributes, namely a TaxObligationID 64016, a TaxPayerPartyID64020, a LevyTypeCode 64024, a LevyTypeName 64028, aStartBillingPeriodID 64032, a StartBillingPeriodName 64036, anEndBillingPeriodID 64040, an EndBillingPeriodName 64044, aValidityStartDate 64048, a ValidityEndDate 64052, a ContractAccountID64056, a RegistrationStatusCode 64060, a RegistrationStatusName 64064, aContactPartyID 64068, an ElectronicFilingCode 64072 and anEmailReminderIndicator 64076. The TaxObligationID 64016 attribute has acardinality of 1 64018 meaning that for each instance of theTaxObligation 64012 entity there is one TaxObligationID 64016 attribute.The TaxPayerPartyID 64020 attribute has a cardinality of 1 64022 meaningthat for each instance of the TaxObligation 64012 entity there is oneTaxPayerPartyID 64020 attribute.

The LevyTypeCode 64024 attribute has a cardinality of 1 64026 meaningthat for each instance of the TaxObligation 64012 entity there is oneLevyTypeCode 64024 attribute. The LevyTypeName 64028 attribute has acardinality of 0 . . . 1 64030 meaning that for each instance of theTaxObligation 64012 entity there may be one LevyTypeName 64028attribute. The StartBillingPeriodID 64032 attribute has a cardinality of1 64034 meaning that for each instance of the TaxObligation 64012 entitythere is one StartBillingPeriodID 64032 attribute. TheStartBillingPeriodName 64036 attribute has a cardinality of 0 . . . 164038 meaning that for each instance of the TaxObligation 64012 entitythere may be one StartBillingPeriodName 64036 attribute. TheEndBillingPeriodID 64040 attribute has a cardinality of 0 . . . 1 64042meaning that for each instance of the TaxObligation 64012 entity theremay be one EndBillingPeriodID 64040 attribute. The EndBillingPeriodName64044 attribute has a cardinality of 0 . . . 1 64046 meaning that foreach instance of the TaxObligation 64012 entity there may be oneEndBillingPeriodName 64044 attribute. The ValidityStartDate 64048attribute has a cardinality of 0 . . . 1 64050 meaning that for eachinstance of the TaxObligation 64012 entity there may be oneValidityStartDate 64048 attribute. The ValidityEndDate 64052 attributehas a cardinality of 0 . . . 1 64054 meaning that for each instance ofthe TaxObligation 64012 entity there may be one ValidityEndDate 64052attribute.

The ContractAccountID 64056 attribute has a cardinality of 1 64058meaning that for each instance of the TaxObligation 64012 entity thereis one ContractAccountID 64056 attribute. The RegistrationStatusCode64060 attribute has a cardinality of 1 64062 meaning that for eachinstance of the TaxObligation 64012 entity there is oneRegistrationStatusCode 64060 attribute. The RegistrationStatusName 64064attribute has a cardinality of 0 . . . 1 64066 meaning that for eachinstance of the TaxObligation 64012 entity there may be oneRegistrationStatusName 64064 attribute. The ContactPartyID 64068attribute has a cardinality of 0 . . . n 64070 meaning that for eachinstance of the TaxObligation 64012 entity there may be one or moreContactPartyID 64068 attributes. The ElectronicFilingCode 64072attribute has a cardinality of 0 . . . 1 64074 meaning that for eachinstance of the TaxObligation 64012 entity there may be oneElectronicFilingCode 64072 attribute. The EmailReminderIndicator 64076attribute has a cardinality of 1 64078 meaning that for each instance ofthe TaxObligation 64012 entity there is one EmailReminderIndicator 64076attribute.

The FilingRule 64080 package includes a FilingRule 64082 entity. TheFilingRule 64080 package includes a Periodicity 64106 package. TheFilingRule 64082 entity has a cardinality of 0 . . . n 64084 meaningthat for each instance of the FilingRule 64080 package there may be oneor more FilingRule 64082 entities. The FilingRule 64082 entity includesvarious attributes, namely an InboundCorrespondenceCategoryCode 64086,an InboundCorrespondenceFirstBillingPeriodID 64090, aGenerationStatusCode 64094, a GenerationStatusName 64098 and anInboundCorrespondenceLastBillingPeriodID 64102. TheInboundCorrespondenceCategoryCode 64086 attribute has a cardinality of 164088 meaning that for each instance of the FilingRule 64082 entitythere is one InboundCorrespondenceCategoryCode 64086 attribute. TheInboundCorrespondenceFirstBillingPeriodID 64090 attribute has acardinality of 1 64092 meaning that for each instance of the FilingRule64082 entity there is one InboundCorrespondenceFirstBillingPeriodID64090 attribute. The GenerationStatusCode 64094 attribute has acardinality of 1 64096 meaning that for each instance of the FilingRule64082 entity there is one GenerationStatusCode 64094 attribute. TheGenerationStatusName 64098 attribute has a cardinality of 0 . . . 164100 meaning that for each instance of the FilingRule 64082 entitythere may be one GenerationStatusName 64098 attribute. TheInboundCorrespondenceLastBillingPeriodID 64102 attribute has acardinality of 0 . . . 1 64104 meaning that for each instance of theFilingRule 64082 entity there may be oneInboundCorrespondenceLastBillingPeriodID 64102 attribute.

The Periodicity 64106 package includes various entities, namely aDeviatingPeriod 64108 and a StandardPeriod 64132. The DeviatingPeriod64108 entity has a cardinality of 0 . . . n 64110 meaning that for eachinstance of the Periodicity 64106 package there may be one or moreDeviatingPeriod 64108 entities. The DeviatingPeriod 64108 entityincludes various attributes, namely a StartDate 64112, an EndDate 64116,a DueDate 64120, a BillingPeriodID 64124 and a BillingPeriodName 64128.The StartDate 64112 attribute has a cardinality of 1 64114 meaning thatfor each instance of the DeviatingPeriod 64108 entity there is oneStartDate 64112 attribute. The EndDate 64116 attribute has a cardinalityof 1 64118 meaning that for each instance of the DeviatingPeriod 64108entity there is one EndDate 64116 attribute. The DueDate 64120 attributehas a cardinality of 0 . . . 1 64122 meaning that for each instance ofthe DeviatingPeriod 64108 entity there may be one DueDate 64120attribute. The BillingPeriodID 64124 attribute has a cardinality of 164126 meaning that for each instance of the DeviatingPeriod 64108 entitythere is one BillingPeriodID 64124 attribute. The BillingPeriodName64128 attribute has a cardinality of 0 . . . 1 64130 meaning that foreach instance of the DeviatingPeriod 64108 entity there may be oneBillingPeriodName 64128 attribute.

The StandardPeriod 64132 entity has a cardinality of 1 . . . n 64134meaning that for each instance of the Periodicity 64106 package thereare one or more StandardPeriod 64132 entities. The StandardPeriod 64132entity includes various attributes, namely a StartDate 64136, an EndDate64140, a DueDate 64144, a BillingPeriodID 64148 and a BillingPeriodName64152. The StartDate 64136 attribute has a cardinality of 1 64138meaning that for each instance of the StandardPeriod 64132 entity thereis one StartDate 64136 attribute. The EndDate 64140 attribute has acardinality of 1 64142 meaning that for each instance of theStandardPeriod 64132 entity there is one EndDate 64140 attribute. TheDueDate 64144 attribute has a cardinality of 0 . . . 1 64146 meaningthat for each instance of the StandardPeriod 64132 entity there may beone DueDate 64144 attribute. The BillingPeriodID 64148 attribute has acardinality of 1 64150 meaning that for each instance of theStandardPeriod 64132 entity there is one BillingPeriodID 64148attribute. The BillingPeriodName 64152 attribute has a cardinality of 0. . . 1 64154 meaning that for each instance of the StandardPeriod 64132entity there may be one BillingPeriodName 64152 attribute.

The FilingExemption 64156 package includes a FilingExemption 64158entity. The FilingExemption 64158 entity has a cardinality of 0 . . . n64160 meaning that for each instance of the FilingExemption 64156package there may be one or more FilingExemption 64158 entities. TheFilingExemption 64158 entity includes various attributes, namely aStartDay 64162, a StartMonth 64166, an EndDay 64170 and an EndMonth64174. The StartDay 64162 attribute has a cardinality of 1 64164 meaningthat for each instance of the FilingExemption 64158 entity there is oneStartDay 64162 attribute. The StartMonth 64166 attribute has acardinality of 1 64168 meaning that for each instance of theFilingExemption 64158 entity there is one StartMonth 64166 attribute.The EndDay 64170 attribute has a cardinality of 1 64172 meaning that foreach instance of the FilingExemption 64158 entity there is one EndDay64170 attribute. The EndMonth 64174 attribute has a cardinality of 164176 meaning that for each instance of the FilingExemption 64158 entitythere is one EndMonth 64174 attribute.

The InvoicingTerms 64178 package includes an InvoicingTerms 64180entity. The InvoicingTerms 64180 entity has a cardinality of 1 64182meaning that for each instance of the InvoicingTerms 64178 package thereis one InvoicingTerms 64180 entity. The InvoicingTerms 64180 entityincludes various attributes, namely a ContractAccountContractReferenceID64184 and a ChargePercent 64188. The ContractAccountContractReferenceID64184 attribute has a cardinality of 0 . . . 1 64186 meaning that foreach instance of the InvoicingTerms 64180 entity there may be oneContractAccountContractReferenceID 64184 attribute. The ChargePercent64188 attribute has a cardinality of 1 64190 meaning that for eachinstance of the InvoicingTerms 64180 entity there is one ChargePercent64188 attribute.

The RegistrationForm 64192 package includes a RegistrationForm 64194entity. The RegistrationForm 64192 package includes a PropertyValuation64210 package. The RegistrationForm 64194 entity has a cardinality of 0. . . n 64196 meaning that for each instance of the RegistrationForm64192 package there may be one or more RegistrationForm 64194 entities.The RegistrationForm 64194 entity includes various attributes, namely aFormTemplateID 64198, a FormVersionID 64202 and a FormStatusCode 64206.The FormTemplateID 64198 attribute has a cardinality of 1 64200 meaningthat for each instance of the RegistrationForm 64194 entity there is oneFormTemplateID 64198 attribute. The FormVersionID 64202 attribute has acardinality of 1 64204 meaning that for each instance of theRegistrationForm 64194 entity there is one FormVersionID 64202attribute. The FormStatusCode 64206 attribute has a cardinality of 0 . .. 1 64208 meaning that for each instance of the RegistrationForm 64194entity there may be one FormStatusCode 64206 attribute.

The PropertyValuation 64210 package includes a PropertyValuation 64212entity. The PropertyValuation 64212 entity has a cardinality of 1 . . .n 64214 meaning that for each instance of the PropertyValuation 64210package there are one or more PropertyValuation 64212 entities. ThePropertyValuation 64212 entity includes a PropertyValuation 64216attribute. The PropertyValuation 64216 attribute has a cardinality of 0. . . 1 64218 meaning that for each instance of the PropertyValuation64212 entity there may be one PropertyValuation 64216 attribute.

The Log 64220 package includes a Log 64222 entity. The Log 64222 entityhas a cardinality of 1 64224 meaning that for each instance of the Log64220 package there is one Log 64222 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 54.

In further detail, FIGS. 65-1 through 65-2 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPByBusinessPartnerQueryMessage_Sync 65000 package. TheTaxObligationERPByBusinessPartnerQueryMessage_Sync 65000 packageincludes a TaxObligationERPByBusinessPartnerQueryMessage_Sync 65002entity. The TaxObligationERPByBusinessPartnerQueryMessage_Sync 65000package includes various packages, namely a MessageHeader 65004, aSelection 65010 and a ProcessingConditions 65038.

The MessageHeader 65004 package includes a MessageHeader 65006 entity.The MessageHeader 65006 entity has a cardinality of 1 65008 meaning thatfor each instance of the MessageHeader 65004 package there is oneMessageHeader 65006 entity.

The Selection 65010 package includes a Selection 65012 entity. TheSelection 65010 package includes a SelectionByTaxPayerPartyID 65016package.

The Selection 65012 entity has a cardinality of 1 65014 meaning that foreach instance of the Selection 65010 package there is one Selection65012 entity. The SelectionByTaxPayerPartyID 65016 package includes aSelectionByTaxPayerPartyID 65018 entity. The SelectionByTaxPayerPartyID65018 entity has a cardinality of 0 . . . n 65020 meaning that for eachinstance of the SelectionByTaxPayerPartyID 65016 package there may beone or more SelectionByTaxPayerPartyID 65018 entities. TheSelectionByTaxPayerPartyID 65018 entity includes various attributes,namely an InclusionExclusionCode 65022, an IntervalBoundaryTypeCode65026, a LowerBoundaryTaxPayerPartyID 65030 and anUpperBoundaryTaxPayerPartyID 65034. The InclusionExclusionCode 65022attribute has a cardinality of 1 65024 meaning that for each instance ofthe SelectionByTaxPayerPartyID 65018 entity there is oneInclusionExclusionCode 65022 attribute. The IntervalBoundaryTypeCode65026 attribute has a cardinality of 1 65028 meaning that for eachinstance of the SelectionByTaxPayerPartyID 65018 entity there is oneIntervalBoundaryTypeCode 65026 attribute. TheLowerBoundaryTaxPayerPartyID 65030 attribute has a cardinality of 0 . .. 1 65032 meaning that for each instance of theSelectionByTaxPayerPartyID 65018 entity there may be oneLowerBoundaryTaxPayerPartyID 65030 attribute. TheUpperBoundaryTaxPayerPartyID 65034 attribute has a cardinality of 0 . .. 1 65036 meaning that for each instance of theSelectionByTaxPayerPartyID 65018 entity there may be oneUpperBoundaryTaxPayerPartyID 65034 attribute.

The ProcessingConditions 65038 package includes aQueryProcessingConditions 65040 entity. The QueryProcessingConditions65040 entity has a cardinality of 0 . . . 1 65042 meaning that for eachinstance of the ProcessingConditions 65038 package there may be oneQueryProcessingConditions 65040 entity. The data types of the variouspackages, entities, and attributes are described with respect to FIG.54.

In further detail, FIGS. 66-1 through 66-8 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPByBusinessPartnerResponseMessage_Sync 66000 package. TheTaxObligationERPByBusinessPartnerResponseMessage_Sync 66000 packageincludes a TaxObligationERPByBusinessPartnerResponseMessage_Sync 66002entity. The TaxObligationERPByBusinessPartnerResponseMessage_Sync 66000package includes various packages, namely a MessageHeader 66004, aTaxObligation 66010, a ProcessingConditions 66188 and a Log 66194.

The MessageHeader 66004 package includes a MessageHeader 66006 entity.The MessageHeader 66006 entity has a cardinality of 1 66008 meaning thatfor each instance of the MessageHeader 66004 package there is oneMessageHeader 66006 entity.

The TaxObligation 66010 package includes a TaxObligation 66012 entity.The TaxObligation 66010 package includes various packages, namely aFilingObligation 66080 and a FilingExemption 66166.

The TaxObligation 66012 entity has a cardinality of 0 . . . n 66014meaning that for each instance of the TaxObligation 66010 package theremay be one or more TaxObligation 66012 entities. The TaxObligation 66012entity includes various attributes, namely a TaxObligationID 66016, aTaxPayerPartyID 66020, a LevyTypeCode 66024, a LevyTypeName 66028, aStartBillingPeriodID 66032, a StartBillingPeriodName 66036, anEndBillingPeriodID 66040, an EndBillingPeriodName 66044, aValidityStartDate 66048, a ValidityEndDate 66052, a ContractAccountID66056, a RegistrationStatusCode 66060, a RegistrationStatusName 66064, aContactPartyID 66068, an ElectronicFilingCode 66072 and anEmailReminderIndicator 66076. The TaxObligationID 66016 attribute has acardinality of 1 66018 meaning that for each instance of theTaxObligation 66012 entity there is one TaxObligationID 66016 attribute.The TaxPayerPartyID 66020 attribute has a cardinality of 1 66022 meaningthat for each instance of the TaxObligation 66012 entity there is oneTaxPayerPartyID 66020 attribute. The LevyTypeCode 66024 attribute has acardinality of 1 66026 meaning that for each instance of theTaxObligation 66012 entity there is one LevyTypeCode 66024 attribute.

The LevyTypeName 66028 attribute has a cardinality of 0 . . . 1 66030meaning that for each instance of the TaxObligation 66012 entity theremay be one LevyTypeName 66028 attribute. The StartBillingPeriodID 66032attribute has a cardinality of 1 66034 meaning that for each instance ofthe TaxObligation 66012 entity there is one StartBillingPeriodID 66032attribute. The StartBillingPeriodName 66036 attribute has a cardinalityof 0 . . . 1 66038 meaning that for each instance of the TaxObligation66012 entity there may be one StartBillingPeriodName 66036 attribute.The EndBillingPeriodID 66040 attribute has a cardinality of 0 . . . 166042 meaning that for each instance of the TaxObligation 66012 entitythere may be one EndBillingPeriodID 66040 attribute. TheEndBillingPeriodName 66044 attribute has a cardinality of 0 . . . 166046 meaning that for each instance of the TaxObligation 66012 entitythere may be one EndBillingPeriodName 66044 attribute. TheValidityStartDate 66048 attribute has a cardinality of 0 . . . 1 66050meaning that for each instance of the TaxObligation 66012 entity theremay be one ValidityStartDate 66048 attribute. The ValidityEndDate 66052attribute has a cardinality of 0 . . . 1 66054 meaning that for eachinstance of the TaxObligation 66012 entity there may be oneValidityEndDate 66052 attribute. The ContractAccountID 66056 attributehas a cardinality of 1 66058 meaning that for each instance of theTaxObligation 66012 entity there is one ContractAccountID 66056attribute.

The RegistrationStatusCode 66060 attribute has a cardinality of 1 66062meaning that for each instance of the TaxObligation 66012 entity thereis one RegistrationStatusCode 66060 attribute. TheRegistrationStatusName 66064 attribute has a cardinality of 0 . . . 166066 meaning that for each instance of the TaxObligation 66012 entitythere may be one RegistrationStatusName 66064 attribute. TheContactPartyID 66068 attribute has a cardinality of 0 . . . n 66070meaning that for each instance of the TaxObligation 66012 entity theremay be one or more ContactPartyID 66068 attributes. TheElectronicFilingCode 66072 attribute has a cardinality of 0 . . . 166074 meaning that for each instance of the TaxObligation 66012 entitythere may be one ElectronicFilingCode 66072 attribute. TheEmailReminderIndicator 66076 attribute has a cardinality of 1 66078meaning that for each instance of the TaxObligation 66012 entity thereis one EmailReminderIndicator 66076 attribute.

The FilingObligation 66080 package includes a FilingObligation 66082entity. The FilingObligation 66082 entity has a cardinality of 0 . . . n66084 meaning that for each instance of the FilingObligation 66080package there may be one or more FilingObligation 66082 entities.

The FilingObligation 66082 entity includes various attributes, namely aFilingObligationUUID 66086, an InboundCorrespondenceCategoryCode 66090,an InboundCorrespondenceCategoryName 66094, a BillingPeriodID 66098, aBillingPeriodName 66102, a BillingStartDate 66106, aCorrespondenceStatusCode 66110, a CorrespondenceStatusName 66114, anInboundCorrespondenceDueDate 66118, an InboundCorrespondenceReceivedDate66122, an InboundCorrespondenceDeferraIDate 66126, a BillingEndDate66130, a ClearingReasonCode 66134, a ClearingReasonName 66138, aLeadingObjectID 66142, a ConsolidationStatusCode 66146, aConsolidationStatusName 66150, an Amount 66154, a CurrencyCode 66158 anda CurrencyName 66162.

The FilingObligationUUID 66086 attribute has a cardinality of 1 66088meaning that for each instance of the FilingObligation 66082 entitythere is one FilingObligationUUID 66086 attribute. TheInboundCorrespondenceCategoryCode 66090 attribute has a cardinality of 166092 meaning that for each instance of the FilingObligation 66082entity there is one InboundCorrespondenceCategoryCode 66090 attribute.The InboundCorrespondenceCategoryName 66094 attribute has a cardinalityof 0 . . . 1 66096 meaning that for each instance of theFilingObligation 66082 entity there may be oneInboundCorrespondenceCategoryName 66094 attribute. The BillingPeriodID66098 attribute has a cardinality of 1 66100 meaning that for eachinstance of the FilingObligation 66082 entity there is oneBillingPeriodID 66098 attribute. The BillingPeriodName 66102 attributehas a cardinality of 0 . . . 1 66104 meaning that for each instance ofthe FilingObligation 66082 entity there may be one BillingPeriodName66102 attribute. The BillingStartDate 66106 attribute has a cardinalityof 1 66108 meaning that for each instance of the FilingObligation 66082entity there is one BillingStartDate 66106 attribute. TheCorrespondenceStatusCode 66110 attribute has a cardinality of 0 . . . 166112 meaning that for each instance of the FilingObligation 66082entity there may be one CorrespondenceStatusCode 66110 attribute.

The CorrespondenceStatusName 66114 attribute has a cardinality of 0 . .. 1 66116 meaning that for each instance of the FilingObligation 66082entity there may be one CorrespondenceStatusName 66114 attribute. TheInboundCorrespondenceDueDate 66118 attribute has a cardinality of 166120 meaning that for each instance of the FilingObligation 66082entity there is one InboundCorrespondenceDueDate 66118 attribute. TheInboundCorrespondenceReceivedDate 66122 attribute has a cardinality of 0. . . 1 66124 meaning that for each instance of the FilingObligation66082 entity there may be one InboundCorrespondenceReceivedDate 66122attribute. The InboundCorrespondenceDeferraIDate 66126 attribute has acardinality of 0 . . . 1 66128 meaning that for each instance of theFilingObligation 66082 entity there may be oneInboundCorrespondenceDeferraIDate 66126 attribute. The BillingEndDate66130 attribute has a cardinality of 1 66132 meaning that for eachinstance of the FilingObligation 66082 entity there is oneBillingEndDate 66130 attribute. The ClearingReasonCode 66134 attributehas a cardinality of 0 . . . 1 66136 meaning that for each instance ofthe FilingObligation 66082 entity there may be one ClearingReasonCode66134 attribute. The ClearingReasonName 66138 attribute has acardinality of 0 . . . 1 66140 meaning that for each instance of theFilingObligation 66082 entity there may be one ClearingReasonName 66138attribute.

The LeadingObjectID 66142 attribute has a cardinality of 0 . . . 1 66144meaning that for each instance of the FilingObligation 66082 entitythere may be one LeadingObjectID 66142 attribute. TheConsolidationStatusCode 66146 attribute has a cardinality of 0 . . . 166148 meaning that for each instance of the FilingObligation 66082entity there may be one ConsolidationStatusCode 66146 attribute. TheConsolidationStatusName 66150 attribute has a cardinality of 0 . . . 166152 meaning that for each instance of the FilingObligation 66082entity there may be one ConsolidationStatusName 66150 attribute. TheAmount 66154 attribute has a cardinality of 0 . . . 1 66156 meaning thatfor each instance of the FilingObligation 66082 entity there may be oneAmount 66154 attribute. The CurrencyCode 66158 attribute has acardinality of 0 . . . 1 66160 meaning that for each instance of theFilingObligation 66082 entity there may be one CurrencyCode 66158attribute. The CurrencyName 66162 attribute has a cardinality of 0 . . .1 66164 meaning that for each instance of the FilingObligation 66082entity there may be one CurrencyName 66162 attribute.

The FilingExemption 66166 package includes a FilingExemption 66168entity. The FilingExemption 66168 entity has a cardinality of 0 . . . n66170 meaning that for each instance of the FilingExemption 66166package there may be one or more FilingExemption 66168 entities. TheFilingExemption 66168 entity includes various attributes, namely aStartDay 66172, a StartMonth 66176, an EndDay 66180 and an EndMonth66184. The StartDay 66172 attribute has a cardinality of 1 66174 meaningthat for each instance of the FilingExemption 66168 entity there is oneStartDay 66172 attribute. The StartMonth 66176 attribute has acardinality of 1 66178 meaning that for each instance of theFilingExemption 66168 entity there is one StartMonth 66176 attribute.The EndDay 66180 attribute has a cardinality of 1 66182 meaning that foreach instance of the FilingExemption 66168 entity there is one EndDay66180 attribute. The EndMonth 66184 attribute has a cardinality of 166186 meaning that for each instance of the FilingExemption 66168 entitythere is one EndMonth 66184 attribute.

The ProcessingConditions 66188 package includes aResponseProcessingConditions 66190 entity. TheResponseProcessingConditions 66190 entity has a cardinality of 1 66192meaning that for each instance of the ProcessingConditions 66188 packagethere is one ResponseProcessingConditions 66190 entity.

The Log 66194 package includes a Log 66196 entity. The Log 66196 entityhas a cardinality of 1 66198 meaning that for each instance of the Log66194 package there is one Log 66196 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 54.

In further detail, FIGS. 67-1 through 67-2 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPLevyTypeByBusinessPartnerQueryMessage_Sync 67000package. The TaxObligationERPLevyTypeByBusinessPartnerQueryMessage_Sync67000 package includes aTaxObligationERPLevyTypeByBusinessPartnerQueryMessage_Sync 67002 entity.The TaxObligationERPLevyTypeByBusinessPartnerQueryMessage_Sync 67000package includes various packages, namely a MessageHeader 67004, aSelection 67010 and a ProcessingConditions 67038.

The MessageHeader 67004 package includes a MessageHeader 67006 entity.The MessageHeader 67006 entity has a cardinality of 1 67008 meaning thatfor each instance of the MessageHeader 67004 package there is oneMessageHeader 67006 entity.

The Selection 67010 package includes aTaxObligationLevyTypeSelectionByBusinessPartner 67012 entity. TheSelection 67010 package includes a SelectionByTaxPayerPartyID 67016package.

The TaxObligationLevyTypeSelectionByBusinessPartner 67012 entity has acardinality of 1 67014 meaning that for each instance of the Selection67010 package there is oneTaxObligationLevyTypeSelectionByBusinessPartner 67012 entity. TheSelectionByTaxPayerPartyID 67016 package includes aSelectionByTaxPayerPartyID 67018 entity. The SelectionByTaxPayerPartyID67018 entity has a cardinality of 0 . . . n 67020 meaning that for eachinstance of the SelectionByTaxPayerPartyID 67016 package there may beone or more SelectionByTaxPayerPartyID 67018 entities. TheSelectionByTaxPayerPartyID 67018 entity includes various attributes,namely an InclusionExclusionCode 67022, an IntervalBoundaryTypeCode67026, a LowerBoundaryTaxPayerPartyID 67030 and anUpperBoundaryTaxPayerPartyID 67034. The InclusionExclusionCode 67022attribute has a cardinality of 1 67024 meaning that for each instance ofthe SelectionByTaxPayerPartyID 67018 entity there is oneInclusionExclusionCode 67022 attribute. The IntervalBoundaryTypeCode67026 attribute has a cardinality of 1 67028 meaning that for eachinstance of the SelectionByTaxPayerPartyID 67018 entity there is oneIntervalBoundaryTypeCode 67026 attribute. TheLowerBoundaryTaxPayerPartyID 67030 attribute has a cardinality of 0 . .. 1 67032 meaning that for each instance of theSelectionByTaxPayerPartyID 67018 entity there may be oneLowerBoundaryTaxPayerPartyID 67030 attribute. TheUpperBoundaryTaxPayerPartyID 67034 attribute has a cardinality of 0 . .. 1 67036 meaning that for each instance of theSelectionByTaxPayerPartyID 67018 entity there may be oneUpperBoundaryTaxPayerPartyID 67034 attribute.

The ProcessingConditions 67038 package includes aQueryProcessingConditions 67040 entity. The QueryProcessingConditions67040 entity has a cardinality of 0 . . . 1 67042 meaning that for eachinstance of the ProcessingConditions 67038 package there may be oneQueryProcessingConditions 67040 entity. The data types of the variouspackages, entities, and attributes are described with respect to FIG.54.

In further detail, FIGS. 68-1 through 68-2 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPLevyTypeByBusinessPartnerResponseMessage_Sync 68000package. TheTaxObligationERPLevyTypeByBusinessPartnerResponseMessage_Sync 68000package includes aTaxObligationERPLevyTypeByBusinessPartnerResponseMessage_Sync 68002entity. TheTaxObligationERPLevyTypeByBusinessPartnerResponseMessage_Sync 68000package includes various packages, namely a MessageHeader 68004, aTaxObligation 68010, a ProcessingConditions 68040 and a Log 68046.

The MessageHeader 68004 package includes a MessageHeader 68006 entity.The MessageHeader 68006 entity has a cardinality of 1 68008 meaning thatfor each instance of the MessageHeader 68004 package there is oneMessageHeader 68006 entity.

The TaxObligation 68010 package includes a TaxObligation 68012 entity.The TaxObligation 68012 entity has a cardinality of 0 . . . n 68014meaning that for each instance of the TaxObligation 68010 package theremay be one or more TaxObligation 68012 entities. The TaxObligation 68012entity includes various attributes, namely a TaxObligationID 68016, aTaxPayerPartyID 68020, a LevyTypeCode 68024, a LevyTypeName 68028, aStartBillingPeriodID 68032 and a StartBillingPeriodName 68036. TheTaxObligationID 68016 attribute has a cardinality of 1 68018 meaningthat for each instance of the TaxObligation 68012 entity there is oneTaxObligationID 68016 attribute. The TaxPayerPartyID 68020 attribute hasa cardinality of 1 68022 meaning that for each instance of theTaxObligation 68012 entity there is one TaxPayerPartyID 68020 attribute.The LevyTypeCode 68024 attribute has a cardinality of 1 68026 meaningthat for each instance of the TaxObligation 68012 entity there is oneLevyTypeCode 68024 attribute. The LevyTypeName 68028 attribute has acardinality of 0 . . . 1 68030 meaning that for each instance of theTaxObligation 68012 entity there may be one LevyTypeName 68028attribute. The StartBillingPeriodID 68032 attribute has a cardinality of1 68034 meaning that for each instance of the TaxObligation 68012 entitythere is one StartBillingPeriodID 68032 attribute. TheStartBillingPeriodName 68036 attribute has a cardinality of 0 . . . 168038 meaning that for each instance of the TaxObligation 68012 entitythere may be one StartBillingPeriodName 68036 attribute.

The ProcessingConditions 68040 package includes aResponseProcessingConditions 68042 entity. TheResponseProcessingConditions 68042 entity has a cardinality of 1 68044meaning that for each instance of the ProcessingConditions 68040 packagethere is one ResponseProcessingConditions 68042 entity.

The Log 68046 package includes a Log 68048 entity. The Log 68048 entityhas a cardinality of 1 68050 meaning that for each instance of the Log68046 package there is one Log 68048 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 54.

In further detail, FIG. 69 illustrates an example configuration of anElement Structure that includes aTaxObligationERPRegistrationFormByIdQueryMessage_Sync 69000 package. TheTaxObligationERPRegistrationFormByIdQueryMessage_Sync 69000 packageincludes a TaxObligationERPRegistrationFormByIdQueryMessage_Sync 69002entity. The TaxObligationERPRegistrationFormByIdQueryMessage_Sync 69000package includes various packages, namely a MessageHeader 69004 and aSelection 69010.

The MessageHeader 69004 package includes a MessageHeader 69006 entity.The MessageHeader 69006 entity has a cardinality of 1 69008 meaning thatfor each instance of the MessageHeader 69004 package there is oneMessageHeader 69006 entity.

The Selection 69010 package includes aTaxObligationRegistrationFormSelectionById 69012 entity. TheTaxObligationRegistrationFormSelectionById 69012 entity has acardinality of 1 69014 meaning that for each instance of the Selection69010 package there is one TaxObligationRegistrationFormSelectionById69012 entity. The TaxObligationRegistrationFormSelectionById 69012entity includes a TaxObligationID 69016 attribute. The TaxObligationID69016 attribute has a cardinality of 1 69018 meaning that for eachinstance of the TaxObligationRegistrationFormSelectionById 69012 entitythere is one TaxObligationID 69016 attribute. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 54.

In further detail, FIGS. 70-1 through 70-3 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPRegistrationFormByIdResponseMessage_Sync 70000 package.The TaxObligationERPRegistrationFormByIdResponseMessage_Sync 70000package includes aTaxObligationERPRegistrationFormByIdResponseMessage_Sync 70002 entity.The TaxObligationERPRegistrationFormByIdResponseMessage_Sync 70000package includes various packages, namely a MessageHeader 70004, aTaxObligation 70010 and a Log 70068.

The MessageHeader 70004 package includes a MessageHeader 70006 entity.The MessageHeader 70006 entity has a cardinality of 1 70008 meaning thatfor each instance of the MessageHeader 70004 package there is oneMessageHeader 70006 entity.

The TaxObligation 70010 package includes a TaxObligation 70012 entity.The TaxObligation 70010 package includes a RegistrationForm 70040package.

The TaxObligation 70012 entity has a cardinality of 0 . . . 1 70014meaning that for each instance of the TaxObligation 70010 package theremay be one TaxObligation 70012 entity. The TaxObligation 70012 entityincludes various attributes, namely a TaxObligationID 70016, aTaxPayerPartyID 70020, a LevyTypeCode 70024, a LevyTypeName 70028, aStartBillingPeriodID 70032 and a StartBillingPeriodName 70036. TheTaxObligationID 70016 attribute has a cardinality of 1 70018 meaningthat for each instance of the TaxObligation 70012 entity there is oneTaxObligationID 70016 attribute. The TaxPayerPartyID 70020 attribute hasa cardinality of 1 70022 meaning that for each instance of theTaxObligation 70012 entity there is one TaxPayerPartyID 70020 attribute.The LevyTypeCode 70024 attribute has a cardinality of 1 70026 meaningthat for each instance of the TaxObligation 70012 entity there is oneLevyTypeCode 70024 attribute. The LevyTypeName 70028 attribute has acardinality of 0 . . . 1 70030 meaning that for each instance of theTaxObligation 70012 entity there may be one LevyTypeName 70028attribute. The StartBillingPeriodID 70032 attribute has a cardinality of1 70034 meaning that for each instance of the TaxObligation 70012 entitythere is one StartBillingPeriodID 70032 attribute. TheStartBillingPeriodName 70036 attribute has a cardinality of 0 . . . 170038 meaning that for each instance of the TaxObligation 70012 entitythere may be one StartBillingPeriodName 70036 attribute.

The RegistrationForm 70040 package includes a RegistrationForm 70042entity. The RegistrationForm 70040 package includes a PropertyValuation70058 package.

The RegistrationForm 70042 entity has a cardinality of 0 . . . n 70044meaning that for each instance of the RegistrationForm 70040 packagethere may be one or more RegistrationForm 70042 entities. TheRegistrationForm 70042 entity includes various attributes, namely aFormTemplateID 70046, a FormVersionID 70050 and a FormStatusCode 70054.The FormTemplateID 70046 attribute has a cardinality of 1 70048 meaningthat for each instance of the RegistrationForm 70042 entity there is oneFormTemplateID 70046 attribute. The FormVersionID 70050 attribute has acardinality of 1 70052 meaning that for each instance of theRegistrationForm 70042 entity there is one FormVersionID 70050attribute. The FormStatusCode 70054 attribute has a cardinality of 0 . .. 1 70056 meaning that for each instance of the RegistrationForm 70042entity there may be one FormStatusCode 70054 attribute.

The PropertyValuation 70058 package includes a PropertyValuation 70060entity. The PropertyValuation 70060 entity has a cardinality of 0 . . .1 70062 meaning that for each instance of the PropertyValuation 70058package there may be one PropertyValuation 70060 entity. ThePropertyValuation 70060 entity includes a PropertyValuation 70064attribute. The PropertyValuation 70064 attribute has a cardinality of 0. . . 1 70066 meaning that for each instance of the PropertyValuation70060 entity there may be one PropertyValuation 70064 attribute.

The Log 70068 package includes a Log 70070 entity. The Log 70070 entityhas a cardinality of 1 70072 meaning that for each instance of the Log70068 package there is one Log 70070 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 54.

In further detail, FIG. 71 illustrates an example configuration of anElement Structure that includes aTaxObligationERPFilingObligationByIdQueryMessage_Sync 71000 package. TheTaxObligationERPFilingObligationByIdQueryMessage_Sync 71000 packageincludes a TaxObligationERPFilingObligationByIdQueryMessage_Sync 71002entity. The TaxObligationERPFilingObligationByIdQueryMessage_Sync 71000package includes various packages, namely a MessageHeader 71004 and aSelection 71010.

The MessageHeader 71004 package includes a MessageHeader 71006 entity.The MessageHeader 71006 entity has a cardinality of 1 71008 meaning thatfor each instance of the MessageHeader 71004 package there is oneMessageHeader 71006 entity.

The Selection 71010 package includes a TaxObligationFilingObligationById71012 entity. The TaxObligationFilingObligationById 71012 entity has acardinality of 1 71014 meaning that for each instance of the Selection71010 package there is one TaxObligationFilingObligationById 71012entity. The TaxObligationFilingObligationById 71012 entity includes aTaxObligationID 71016 attribute. The TaxObligationID 71016 attribute hasa cardinality of 1 71018 meaning that for each instance of theTaxObligationFilingObligationById 71012 entity there is oneTaxObligationID 71016 attribute. The data types of the various packages,entities, and attributes are described with respect to FIG. 54.

In further detail, FIGS. 72-1 through 72-5 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPFilingObligationByIdResponseMessage_Sync 72000 package.The TaxObligationERPFilingObligationByIdResponseMessage_Sync 72000package includes aTaxObligationERPFilingObligationByIdResponseMessage_Sync 72002 entity.The TaxObligationERPFilingObligationByIdResponseMessage_Sync 72000package includes various packages, namely a MessageHeader 72004, aTaxObligation 72010 and a Log 72110.

The MessageHeader 72004 package includes a MessageHeader 72006 entity.The MessageHeader 72006 entity has a cardinality of 1 72008 meaning thatfor each instance of the MessageHeader 72004 package there is oneMessageHeader 72006 entity.

The TaxObligation 72010 package includes a TaxObligation 72012 entity.The TaxObligation 72010 package includes a FilingObligation 72036package. The TaxObligation 72012 entity has a cardinality of 0 . . . 172014 meaning that for each instance of the TaxObligation 72010 packagethere may be one TaxObligation 72012 entity. The TaxObligation 72012entity includes various attributes, namely a TaxObligationID 72016, aLevyTypeCode 72020, a LevyTypeName 72024, a StartBillingPeriodID 72028and a StartBillingPeriodName 72032. The TaxObligationID 72016 attributehas a cardinality of 1 72018 meaning that for each instance of theTaxObligation 72012 entity there is one TaxObligationID 72016 attribute.The LevyTypeCode 72020 attribute has a cardinality of 1 72022 meaningthat for each instance of the TaxObligation 72012 entity there is oneLevyTypeCode 72020 attribute. The LevyTypeName 72024 attribute has acardinality of 0 . . . 1 72026 meaning that for each instance of theTaxObligation 72012 entity there may be one LevyTypeName 72024attribute. The StartBillingPeriodID 72028 attribute has a cardinality of1 72030 meaning that for each instance of the TaxObligation 72012 entitythere is one StartBillingPeriodID 72028 attribute. TheStartBillingPeriodName 72032 attribute has a cardinality of 0 . . . 172034 meaning that for each instance of the TaxObligation 72012 entitythere may be one StartBillingPeriodName 72032 attribute. TheFilingObligation 72036 package includes a FilingObligation 72038 entity.The FilingObligation 72038 entity has a cardinality of 0 . . . n 72040meaning that for each instance of the FilingObligation 72036 packagethere may be one or more FilingObligation 72038 entities. TheFilingObligation 72038 entity includes various attributes, namely aFilingObligationUUID 72042, an InboundCorrespondenceCategoryCode 72046,an InboundCorrespondenceCategoryName 72050, a BillingPeriodID 72054, aBillingPeriodName 72058, a BillingStartDate 72062, aCorrespondenceStatusCode 72066, a CorrespondenceStatusName 72070, anInboundCorrespondenceDueDate 72074, an InboundCorrespondenceReceivedDate72078, an InboundCorrespondenceDeferraIDate 72082, a BillingEndDate72086, a ClearingReasonCode 72090, a ClearingReasonName 72094, an Amount72098, a CurrencyCode 72102 and a CurrencyName 72106. TheFilingObligationUUID 72042 attribute has a cardinality of 0 . . . 172044 meaning that for each instance of the FilingObligation 72038entity there may be one FilingObligationUUID 72042 attribute. TheInboundCorrespondenceCategoryCode 72046 attribute has a cardinality of 0. . . 1 72048 meaning that for each instance of the FilingObligation72038 entity there may be one InboundCorrespondenceCategoryCode 72046attribute.

The InboundCorrespondenceCategoryName 72050 attribute has a cardinalityof 0 . . . 1 72052 meaning that for each instance of theFilingObligation 72038 entity there may be oneInboundCorrespondenceCategoryName 72050 attribute. The BillingPeriodID72054 attribute has a cardinality of 0 . . . 1 72056 meaning that foreach instance of the FilingObligation 72038 entity there may be oneBillingPeriodID 72054 attribute. The BillingPeriodName 72058 attributehas a cardinality of 0 . . . 1 72060 meaning that for each instance ofthe FilingObligation 72038 entity there may be one BillingPeriodName72058 attribute. The BillingStartDate 72062 attribute has a cardinalityof 0 . . . 1 72064 meaning that for each instance of theFilingObligation 72038 entity there may be one BillingStartDate 72062attribute. The CorrespondenceStatusCode 72066 attribute has acardinality of 0 . . . 1 72068 meaning that for each instance of theFilingObligation 72038 entity there may be one CorrespondenceStatusCode72066 attribute. The CorrespondenceStatusName 72070 attribute has acardinality of 0 . . . 1 72072 meaning that for each instance of theFilingObligation 72038 entity there may be one CorrespondenceStatusName72070 attribute. The InboundCorrespondenceDueDate 72074 attribute has acardinality of 1 72076 meaning that for each instance of theFilingObligation 72038 entity there is one InboundCorrespondenceDueDate72074 attribute.

The InboundCorrespondenceReceivedDate 72078 attribute has a cardinalityof 0 . . . 1 72080 meaning that for each instance of theFilingObligation 72038 entity there may be oneInboundCorrespondenceReceivedDate 72078 attribute. TheInboundCorrespondenceDeferraIDate 72082 attribute has a cardinality of 0. . . 1 72084 meaning that for each instance of the FilingObligation72038 entity there may be one InboundCorrespondenceDeferraIDate 72082attribute. The BillingEndDate 72086 attribute has a cardinality of 0 . .. 1 72088 meaning that for each instance of the FilingObligation 72038entity there may be one BillingEndDate 72086 attribute. TheClearingReasonCode 72090 attribute has a cardinality of 0 . . . 1 72092meaning that for each instance of the FilingObligation 72038 entitythere may be one ClearingReasonCode 72090 attribute. TheClearingReasonName 72094 attribute has a cardinality of 0 . . . 1 72096meaning that for each instance of the FilingObligation 72038 entitythere may be one ClearingReasonName 72094 attribute. The Amount 72098attribute has a cardinality of 1 72100 meaning that for each instance ofthe FilingObligation 72038 entity there is one Amount 72098 attribute.The CurrencyCode 72102 attribute has a cardinality of 1 72104 meaningthat for each instance of the FilingObligation 72038 entity there is oneCurrencyCode 72102 attribute. The CurrencyName 72106 attribute has acardinality of 0 . . . 1 72108 meaning that for each instance of theFilingObligation 72038 entity there may be one CurrencyName 72106attribute.

The Log 72110 package includes a Log 72112 entity. The Log 72112 entityhas a cardinality of 1 72114 meaning that for each instance of the Log72110 package there is one Log 72112 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 54.

In further detail, FIG. 73 illustrates an example configuration of anElement Structure that includes a TaxObligationERPByIdQueryMessage_Sync73000 package. The TaxObligationERPByIdQueryMessage_Sync 73000 packageincludes a TaxObligationERPByIdQueryMessage_Sync 73002 entity. TheTaxObligationERPByIdQueryMessage_Sync 73000 package includes variouspackages, namely a MessageHeader 73004 and a Selection 73010.

The MessageHeader 73004 package includes a MessageHeader 73006 entity.The MessageHeader 73006 entity has a cardinality of 1 73008 meaning thatfor each instance of the MessageHeader 73004 package there is oneMessageHeader 73006 entity.

The Selection 73010 package includes a TaxObligationSelectionById 73012entity. The TaxObligationSelectionById 73012 entity has a cardinality of1 73014 meaning that for each instance of the Selection 73010 packagethere is one TaxObligationSelectionById 73012 entity. TheTaxObligationSelectionById 73012 entity includes a TaxObligationID 73016attribute. The TaxObligationID 73016 attribute has a cardinality of 173018 meaning that for each instance of the TaxObligationSelectionById73012 entity there is one TaxObligationID 73016 attribute. The datatypes of the various packages, entities, and attributes are describedwith respect to FIG. 54.

In further detail, FIGS. 74-1 through 74-12 illustrate an exampleconfiguration of an Element Structure that includes aTaxObligationERPByIdResponseMessage_Sync 74000 package. TheTaxObligationERPByIdResponseMessage_Sync 74000 package includes aTaxObligationERPByIdResponseMessage_Sync 74002 entity. TheTaxObligationERPByIdResponseMessage_Sync 74000 package includes variouspackages, namely a MessageHeader 74004, a TaxObligation 74010 and a Log74290.

The MessageHeader 74004 package includes a MessageHeader 74006 entity.The MessageHeader 74006 entity has a cardinality of 1 74008 meaning thatfor each instance of the MessageHeader 74004 package there is oneMessageHeader 74006 entity.

The TaxObligation 74010 package includes a TaxObligation 74012 entity.The TaxObligation 74010 package includes various packages, namely aFilingObligation 74080, a FilingRule 74154, a FilingExemption 74226, anInvoicingTerms 74248 and a RegistrationForm 74262.

The TaxObligation 74012 entity has a cardinality of 0 . . . 1 74014meaning that for each instance of the TaxObligation 74010 package theremay be one TaxObligation 74012 entity. The TaxObligation 74012 entityincludes various attributes, namely a TaxObligationID 74016, aTaxPayerPartyID 74020, a LevyTypeCode 74024, a LevyTypeName 74028, aContractAccountID 74032, a RegistrationStatusCode 74036, aRegistrationStatusName 74040, a StartBillingPeriodID 74044, aStartBillingPeriodName 74048, an EndBillingPeriodID 74052, anEndBillingPeriodName 74056, a ValidityStartDate 74060, a ValidityEndDate74064, a ContactPartyID 74068, an ElectronicFilingCode 74072 and anEmailReminderIndicator 74076. The TaxObligationID 74016 attribute has acardinality of 1 74018 meaning that for each instance of theTaxObligation 74012 entity there is one TaxObligationID 74016 attribute.The TaxPayerPartyID 74020 attribute has a cardinality of 1 74022 meaningthat for each instance of the TaxObligation 74012 entity there is oneTaxPayerPartyID 74020 attribute. The LevyTypeCode 74024 attribute has acardinality of 1 74026 meaning that for each instance of theTaxObligation 74012 entity there is one LevyTypeCode 74024 attribute.

The LevyTypeName 74028 attribute has a cardinality of 0 . . . 1 74030meaning that for each instance of the TaxObligation 74012 entity theremay be one LevyTypeName 74028 attribute. The ContractAccountID 74032attribute has a cardinality of 1 74034 meaning that for each instance ofthe TaxObligation 74012 entity there is one ContractAccountID 74032attribute. The RegistrationStatusCode 74036 attribute has a cardinalityof 1 74038 meaning that for each instance of the TaxObligation 74012entity there is one RegistrationStatusCode 74036 attribute. TheRegistrationStatusName 74040 attribute has a cardinality of 0 . . . 174042 meaning that for each instance of the TaxObligation 74012 entitythere may be one RegistrationStatusName 74040 attribute. TheStartBillingPeriodID 74044 attribute has a cardinality of 1 74046meaning that for each instance of the TaxObligation 74012 entity thereis one StartBillingPeriodID 74044 attribute. The StartBillingPeriodName74048 attribute has a cardinality of 0 . . . 1 74050 meaning that foreach instance of the TaxObligation 74012 entity there may be oneStartBillingPeriodName 74048 attribute. The EndBillingPeriodID 74052attribute has a cardinality of 0 . . . 1 74054 meaning that for eachinstance of the TaxObligation 74012 entity there may be oneEndBillingPeriodID 74052 attribute.

The EndBillingPeriodName 74056 attribute has a cardinality of 0 . . . 174058 meaning that for each instance of the TaxObligation 74012 entitythere may be one EndBillingPeriodName 74056 attribute. TheValidityStartDate 74060 attribute has a cardinality of 0 . . . 1 74062meaning that for each instance of the TaxObligation 74012 entity theremay be one ValidityStartDate 74060 attribute. The ValidityEndDate 74064attribute has a cardinality of 0 . . . 1 74066 meaning that for eachinstance of the TaxObligation 74012 entity there may be oneValidityEndDate 74064 attribute. The ContactPartyID 74068 attribute hasa cardinality of 0 . . . n 74070 meaning that for each instance of theTaxObligation 74012 entity there may be one or more ContactPartyID 74068attributes. The ElectronicFilingCode 74072 attribute has a cardinalityof 0 . . . 1 74074 meaning that for each instance of the TaxObligation74012 entity there may be one ElectronicFilingCode 74072 attribute. TheEmailReminderIndicator 74076 attribute has a cardinality of 1 74078meaning that for each instance of the TaxObligation 74012 entity thereis one EmailReminderIndicator 74076 attribute.

The FilingObligation 74080 package includes a FilingObligation 74082entity. The FilingObligation 74082 entity has a cardinality of 0 . . . n74084 meaning that for each instance of the FilingObligation 74080package there may be one or more FilingObligation 74082 entities. TheFilingObligation 74082 entity includes various attributes, namely aFilingObligationUUID 74086, an InboundCorrespondenceCategoryCode 74090,an InboundCorrespondenceCategoryName 74094, a BillingPeriodID 74098, aBillingPeriodName 74102, a BillingStartDate 74106, aCorrespondenceStatusCode 74110, a CorrespondenceStatusName 74114, anInboundCorrespondenceDueDate 74118, an InboundCorrespondenceReceivedDate74122, an InboundCorrespondenceDeferraIDate 74126, a BillingEndDate74130, a ClearingReasonCode 74134, a ClearingReasonName 74138, an Amount74142, a CurrencyCode 74146 and a CurrencyName 74150. TheFilingObligationUUID 74086 attribute has a cardinality of 1 74088meaning that for each instance of the FilingObligation 74082 entitythere is one FilingObligationUUID 74086 attribute. TheInboundCorrespondenceCategoryCode 74090 attribute has a cardinality of 174092 meaning that for each instance of the FilingObligation 74082entity there is one InboundCorrespondenceCategoryCode 74090 attribute.

The InboundCorrespondenceCategoryName 74094 attribute has a cardinalityof 0 . . . 1 74096 meaning that for each instance of theFilingObligation 74082 entity there may be oneInboundCorrespondenceCategoryName 74094 attribute. The BillingPeriodID74098 attribute has a cardinality of 1 74100 meaning that for eachinstance of the FilingObligation 74082 entity there is oneBillingPeriodID 74098 attribute. The BillingPeriodName 74102 attributehas a cardinality of 0 . . . 1 74104 meaning that for each instance ofthe FilingObligation 74082 entity there may be one BillingPeriodName74102 attribute. The BillingStartDate 74106 attribute has a cardinalityof 1 74108 meaning that for each instance of the FilingObligation 74082entity there is one BillingStartDate 74106 attribute. TheCorrespondenceStatusCode 74110 attribute has a cardinality of 0 . . . 174112 meaning that for each instance of the FilingObligation 74082entity there may be one CorrespondenceStatusCode 74110 attribute. TheCorrespondenceStatusName 74114 attribute has a cardinality of 0 . . . 174116 meaning that for each instance of the FilingObligation 74082entity there may be one CorrespondenceStatusName 74114 attribute. TheInboundCorrespondenceDueDate 74118 attribute has a cardinality of 174120 meaning that for each instance of the FilingObligation 74082entity there is one InboundCorrespondenceDueDate 74118 attribute.

The InboundCorrespondenceReceivedDate 74122 attribute has a cardinalityof 0 . . . 1 74124 meaning that for each instance of theFilingObligation 74082 entity there may be oneInboundCorrespondenceReceivedDate 74122 attribute. TheInboundCorrespondenceDeferraIDate 74126 attribute has a cardinality of 0. . . 1 74128 meaning that for each instance of the FilingObligation74082 entity there may be one InboundCorrespondenceDeferraIDate 74126attribute. The BillingEndDate 74130 attribute has a cardinality of 174132 meaning that for each instance of the FilingObligation 74082entity there is one BillingEndDate 74130 attribute. TheClearingReasonCode 74134 attribute has a cardinality of 0 . . . 1 74136meaning that for each instance of the FilingObligation 74082 entitythere may be one ClearingReasonCode 74134 attribute. TheClearingReasonName 74138 attribute has a cardinality of 0 . . . 1 74140meaning that for each instance of the FilingObligation 74082 entitythere may be one ClearingReasonName 74138 attribute. The Amount 74142attribute has a cardinality of 0 . . . 1 74144 meaning that for eachinstance of the FilingObligation 74082 entity there may be one Amount74142 attribute. The CurrencyCode 74146 attribute has a cardinality of 0. . . 1 74148 meaning that for each instance of the FilingObligation74082 entity there may be one CurrencyCode 74146 attribute. TheCurrencyName 74150 attribute has a cardinality of 0 . . . 1 74152meaning that for each instance of the FilingObligation 74082 entitythere may be one CurrencyName 74150 attribute.

The FilingRule 74154 package includes a FilingRule 74156 entity. TheFilingRule 74154 package includes a Periodicity 74176 package.

The FilingRule 74156 entity has a cardinality of 0 . . . n 74158 meaningthat for each instance of the FilingRule 74154 package there may be oneor more FilingRule 74156 entities. The FilingRule 74156 entity includesvarious attributes, namely an InboundCorrespondenceCategoryCode 74160,an InboundCorrespondenceFirstBillingPeriodID 74164, a GenerationMode74168 and an InboundCorrespondenceLastBillingPeriodID 74172. TheInboundCorrespondenceCategoryCode 74160 attribute has a cardinality of 174162 meaning that for each instance of the FilingRule 74156 entitythere is one InboundCorrespondenceCategoryCode 74160 attribute. TheInboundCorrespondenceFirstBillingPeriodID 74164 attribute has acardinality of 1 74166 meaning that for each instance of the FilingRule74156 entity there is one InboundCorrespondenceFirstBillingPeriodID74164 attribute. The GenerationMode 74168 attribute has a cardinality of1 74170 meaning that for each instance of the FilingRule 74156 entitythere is one GenerationMode 74168 attribute. TheInboundCorrespondenceLastBillingPeriodID 74172 attribute has acardinality of 0 . . . 1 74174 meaning that for each instance of theFilingRule 74156 entity there may be oneInboundCorrespondenceLastBillingPeriodID 74172 attribute.

The Periodicity 74176 package includes various entities, namely aDeviatingPeriod 74178 and a StandardPeriod 74202. The DeviatingPeriod74178 entity has a cardinality of 0 . . . n 74180 meaning that for eachinstance of the Periodicity 74176 package there may be one or moreDeviatingPeriod 74178 entities. The DeviatingPeriod 74178 entityincludes various attributes, namely a StartDate 74182, an EndDate 74186,a DueDate 74190, a BillingPeriodID 74194 and a BillingPeriodName 74198.The StartDate 74182 attribute has a cardinality of 1 74184 meaning thatfor each instance of the DeviatingPeriod 74178 entity there is oneStartDate 74182 attribute. The EndDate 74186 attribute has a cardinalityof 1 74188 meaning that for each instance of the DeviatingPeriod 74178entity there is one EndDate 74186 attribute. The DueDate 74190 attributehas a cardinality of 0 . . . 1 74192 meaning that for each instance ofthe DeviatingPeriod 74178 entity there may be one DueDate 74190attribute. The BillingPeriodID 74194 attribute has a cardinality of 174196 meaning that for each instance of the DeviatingPeriod 74178 entitythere is one BillingPeriodID 74194 attribute. The BillingPeriodName74198 attribute has a cardinality of 0 . . . 1 74200 meaning that foreach instance of the DeviatingPeriod 74178 entity there may be oneBillingPeriodName 74198 attribute.

The StandardPeriod 74202 entity has a cardinality of 1 . . . n 74204meaning that for each instance of the Periodicity 74176 package thereare one or more StandardPeriod 74202 entities. The StandardPeriod 74202entity includes various attributes, namely a StartDate 74206, an EndDate74210, a DueDate 74214, a BillingPeriodID 74218 and a BillingPeriodName74222. The StartDate 74206 attribute has a cardinality of 1 74208meaning that for each instance of the StandardPeriod 74202 entity thereis one StartDate 74206 attribute. The EndDate 74210 attribute has acardinality of 1 74212 meaning that for each instance of theStandardPeriod 74202 entity there is one EndDate 74210 attribute. TheDueDate 74214 attribute has a cardinality of 0 . . . 1 74216 meaningthat for each instance of the StandardPeriod 74202 entity there may beone DueDate 74214 attribute. The BillingPeriodID 74218 attribute has acardinality of 1 74220 meaning that for each instance of theStandardPeriod 74202 entity there is one BillingPeriodID 74218attribute. The BillingPeriodName 74222 attribute has a cardinality of 0. . . 1 74224 meaning that for each instance of the StandardPeriod 74202entity there may be one BillingPeriodName 74222 attribute.

The FilingExemption 74226 package includes a FilingExemption 74228entity. The FilingExemption 74228 entity has a cardinality of 0 . . . n74230 meaning that for each instance of the FilingExemption 74226package there may be one or more FilingExemption 74228 entities. TheFilingExemption 74228 entity includes various attributes, namely aStartDay 74232, a StartMonth 74236, an EndDay 74240 and an EndMonth74244. The StartDay 74232 attribute has a cardinality of 1 74234 meaningthat for each instance of the FilingExemption 74228 entity there is oneStartDay 74232 attribute. The StartMonth 74236 attribute has acardinality of 1 74238 meaning that for each instance of theFilingExemption 74228 entity there is one StartMonth 74236 attribute.The EndDay 74240 attribute has a cardinality of 1 74242 meaning that foreach instance of the FilingExemption 74228 entity there is one EndDay74240 attribute. The EndMonth 74244 attribute has a cardinality of 174246 meaning that for each instance of the FilingExemption 74228 entitythere is one EndMonth 74244 attribute.

The InvoicingTerms 74248 package includes an InvoicingTerms 74250entity. The InvoicingTerms 74250 entity has a cardinality of 1 74252meaning that for each instance of the InvoicingTerms 74248 package thereis one InvoicingTerms 74250 entity. The InvoicingTerms 74250 entityincludes various attributes, namely a ContractAccountContractReferenceID74254 and a ChargePercent 74258. The ContractAccountContractReferenceID74254 attribute has a cardinality of 0 . . . 1 74256 meaning that foreach instance of the InvoicingTerms 74250 entity there may be oneContractAccountContractReferenceID 74254 attribute. The ChargePercent74258 attribute has a cardinality of 1 74260 meaning that for eachinstance of the InvoicingTerms 74250 entity there is one ChargePercent74258 attribute.

The RegistrationForm 74262 package includes a RegistrationForm 74264entity. The RegistrationForm 74262 package includes a PropertyValuation74280 package. The RegistrationForm 74264 entity has a cardinality of 0. . . n 74266 meaning that for each instance of the RegistrationForm74262 package there may be one or more RegistrationForm 74264 entities.The RegistrationForm 74264 entity includes various attributes, namely aFormTemplateID 74268, a FormVersionID 74272 and a FormStatus 74276. TheFormTemplateID 74268 attribute has a cardinality of 1 74270 meaning thatfor each instance of the RegistrationForm 74264 entity there is oneFormTemplateID 74268 attribute. The FormVersionID 74272 attribute has acardinality of 1 74274 meaning that for each instance of theRegistrationForm 74264 entity there is one FormVersionID 74272attribute. The FormStatus 74276 attribute has a cardinality of 0 . . . 174278 meaning that for each instance of the RegistrationForm 74264entity there may be one FormStatus 74276 attribute.

The PropertyValuation 74280 package includes a PropertyValuation 74282entity. The PropertyValuation 74282 entity has a cardinality of 1 . . .n 74284 meaning that for each instance of the PropertyValuation 74280package there are one or more PropertyValuation 74282 entities. ThePropertyValuation 74282 entity includes a PropertyValuation 74286attribute. The PropertyValuation 74286 attribute has a cardinality of 0. . . 1 74288 meaning that for each instance of the PropertyValuation74282 entity there may be one PropertyValuation 74286 attribute.

The Log 74290 package includes a Log 74292 entity. The Log 74292 entityhas a cardinality of 1 74294 meaning that for each instance of the Log74290 package there is one Log 74292 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 54.

TaxReturn Interfaces

A tax return includes a person's, company's or organization's taxdetails, which taxpayers, or their legal representatives may completeand send to a tax authority. Tax returns are generally prepared usingforms prescribed by a tax authority. The TaxReturn interface performsvarious operations, namely aTaxReturnERPByBusinessPartnerQueryResponse_In, aTaxReturnERPByIdQueryResponse_In, aTaxReturnERPCreateRequestConfirmation_In, aTaxReturnERPValidateRequestConfirmation_In, and aTaxReturnERPChangeRequestConfirmation_In.

The TaxReturnERPByBusinessPartnerQueryResponse_In operation can findincoming tax returns by revenue type and tax assessment periods. TheTaxReturnERPByBusinessPartnerQueryResponse_In operation includes variousmessage types, namely a TaxReturnERPByBusinessPartnerQuery_sync and aTaxReturnERPByBusinessPartnerResponse_sync. The structure of theTaxReturnERPByBusinessPartnerQuery_sync message type is specified by aTaxReturnERPByBusinessPartnerQueryMessage_sync message data type. Thestructure of the TaxReturnERPByBusinessPartnerResponse_sync message typeis specified by a TaxReturnERPByBusinessPartnerResponseMessage_syncmessage data type.

The TaxReturnERPByIdQueryResponse_In operation can read incoming taxreturns. The TaxReturnERPByIdQueryResponse_In operation includes variousmessage types, namely a TaxReturnERPByIdQuery_sync and aTaxReturnERPByIdResponse_sync. The structure of theTaxReturnERPByIdQuery_sync message type is specified by aTaxReturnERPByIdQueryMessage_sync message data type. The structure ofthe TaxReturnERPByIdResponse_sync message type is specified by aTaxReturnERPByIdResponseMessage_sync message data type.

The TaxReturnERPCreateRequestConfirmation_In operation can create taxreturn. The TaxReturnERPCreateRequestConfirmation_In operation includesvarious message types, namely a TaxReturnERPCreateRequest_sync and aTaxReturnERPCreateConfirmation_sync. The structure of theTaxReturnERPCreateRequest_sync message type is specified by aTaxReturnERPCreateRequestMessage_sync message data type. The structureof the TaxReturnERPCreateConfirmation_sync message type is specified bya TaxReturnERPCreateConfirmationMessage_sync message data type.

The TaxReturnERPValidateRequestConfirmation_In operation can check ifthe data on the incoming tax declaration is valid and/or consistent. TheTaxReturnERPValidateRequestConfirmation_In operation includes variousmessage types, namely a TaxReturnERPRequestConfirmation_sync and aTaxReturnERPRequestConfirmation_sync. The structure of theTaxReturnERPRequestConfirmation_sync message type is specified by aTaxReturnERPValidateRequestMessage_sync message data type. The structureof the TaxReturnERPRequestConfirmation_sync message type is specified bya TaxReturnERPValidateConfirmationMessage_sync message data type.

The TaxReturnERPChangeRequestConfirmation_In operation can change on ormore tax returns. The TaxReturnERPChangeRequestConfirmation_In operationincludes various message types, namely a TaxReturnERPChangeRequest_syncand a TaxReturnERPChangeConfirmation_sync. The structure of theTaxReturnERPChangeRequest_sync message type is specified by aTaxReturnERPChangeRequestMessage_sync message data type. The structureof the TaxReturnERPChangeConfirmation_sync message type is specified bya TaxReturnERPChangeConfirmationMessage_sync message data type.

The message choreography of FIG. 75 describes a possible logicalsequence of messages that can be used to realize a Tax Return businessscenario. A “Requester” system 75000 can query tax return ERPinformation by business partner from a “Tax Processing” system 75002using a TaxReturnERPByBusinessPartnerQuery_sync message 75004 as shown,for example, in FIG. 75. The “Tax Processing” system 75002 can respondto the query using a TaxReturnERPByBusinessPartnerResponse_sync 75006 asshown, for example, in FIG. 75.

The “Requester” system 75000 can query tax return ERP information by IDin the “Tax Processing” system 75002 using a TaxReturnERPByIDQuery_syncmessage 75008 as shown, for example, in FIG. 75. The “Tax Processing”system 75002 can respond to the query using aTaxReturnERPByIDResponse_sync 75010 as shown, for example, in FIG. 75.

The “Requester” system 75000 can request to create tax return ERPinformation in the “Tax Processing” system 75002 using aTaxReturnERPCreateRequest_sync message 75012 as shown, for example, inFIG. 75. The “Tax Processing” system 75002 can confirm the request usinga TaxReturnERPCreateConfirmation_sync 75014 as shown, for example, inFIG. 75.

The “Requester” system 75000 can query tax return ERP check informationin the “Tax Processing” system 75002 using a TaxReturnERPCheckQuery_syncmessage 75016 as shown, for example, in FIG. 75. The “Tax Processing”system 75002 can confirm the query using aTaxReturnERPCheckResponse_sync 75018 as shown, for example, in FIG. 75.

The “Requester” system 75000 can query tax return ERP forms informationby revenue type in the “Tax Processing” system 75002 using aTaxReturnERPFormsByRevenueTypeQuery_sync message 75020 as shown, forexample, in FIG. 75. The “Tax Processing” system 75002 can confirm thequery using a TaxReturnERPFormsByRevenueTypeResponse_sync 75022 asshown, for example, in FIG. 75.

FIGS. 76-1 through 76-12 illustrate one example logical configuration ofTaxReturnERPMessage_Sync element structure 76000. Specifically, thesefigures depict the arrangement and hierarchy of various components suchas one or more levels of packages, entities, and datatypes, shown hereas 76000 through 76282. As described above, packages may be used torepresent hierarchy levels. Entities are discrete business elements thatare used during a business transaction. Data types are used to typeobject entities and interfaces with a structure. For example,TaxReturnERPMessage_Sync element structure 76000 includes, among otherthings, MessageHeader 76006. Accordingly, heterogeneous applications maycommunicate using this consistent message configured as such.

Additionally, FIGS. 77-1 through 77-9 illustrate one example logicalconfiguration of TaxReturnERPByBusinessPartnerQueryMessage_Sync elementstructure 77000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 77000 through 77222. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxReturnERPByBusinessPartnerQueryMessage_Syncelement structure 77000 includes, among other things, MessageHeader77006. Accordingly, heterogeneous applications may communicate usingthis consistent message configured as such.

Additionally, FIGS. 78-1 through 78-3 illustrate one example logicalconfiguration of TaxReturnERPByBusinessPartnerResponseMessage_Syncelement structure 78000. Specifically, these figures depict thearrangement and hierarchy of various components such as one or morelevels of packages, entities, and datatypes, shown here as 78000 through78078. As described above, packages may be used to represent hierarchylevels. Entities are discrete business elements that are used during abusiness transaction. Data types are used to type object entities andinterfaces with a structure. For example,TaxReturnERPByBusinessPartnerResponseMessage_Sync element structure78000 includes, among other things, MessageHeader 78006. Accordingly,heterogeneous applications may communicate using this consistent messageconfigured as such.

Additionally, FIG. 79 illustrates one example logical configuration ofTaxReturnERPByIdQueryMessage_Sync element structure 79000. Specifically,this figure depicts the arrangement and hierarchy of various componentssuch as one or more levels of packages, entities, and datatypes, shownhere as 79000 through 79018. As described above, packages may be used torepresent hierarchy levels. Entities are discrete business elements thatare used during a business transaction. Data types are used to typeobject entities and interfaces with a structure. For example,TaxReturnERPByIdQueryMessage_Sync element structure 79000 includes,among other things, MessageHeader 79006. Accordingly, heterogeneousapplications may communicate using this consistent message configured assuch.

Additionally, FIGS. 80-1 through 80-10 illustrate one example logicalconfiguration of TaxReturnERPByIdResponseMessage_Sync element structure80000. Specifically, these figures depict the arrangement and hierarchyof various components such as one or more levels of packages, entities,and datatypes, shown here as 80000 through 80248. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxReturnERPByIdResponseMessage_Sync elementstructure 80000 includes, among other things, MessageHeader 80006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIGS. 81-1 through 81-4 illustrate one example logicalconfiguration of TaxReturnERPCreateRequestMessage_Sync element structure81000. Specifically, these figures depict the arrangement and hierarchyof various components such as one or more levels of packages, entities,and datatypes, shown here as 81000 through 81092. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxReturnERPCreateRequestMessage_Sync elementstructure 81000 includes, among other things, MessageHeader 81006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIGS. 82-1 through 82-10 illustrate one example logicalconfiguration of TaxReturnERPCreateConfirmationMessage_Sync elementstructure 82000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 82000 through 82254. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxReturnERPCreateConfirmationMessage_Syncelement structure 82000 includes, among other things, MessageHeader82006. Accordingly, heterogeneous applications may communicate usingthis consistent message configured as such.

Additionally, FIGS. 83-1 through 83-3 illustrate one example logicalconfiguration of TaxReturnERPValidateRequestMessage_Sync elementstructure 83000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 83000 through 83092. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxReturnERPValidateRequestMessage_Sync elementstructure 83000 includes, among other things, MessageHeader 83006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIGS. 84-1 through 84-10 illustrate one example logicalconfiguration of TaxReturnERPValidateConfirmationMessage_Sync elementstructure 84000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 84000 through 84260. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxReturnERPValidateConfirmationMessage_Syncelement structure 84000 includes, among other things, TaxReturn 84006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIGS. 85-1 through 85-4 illustrate one example logicalconfiguration of TaxReturnERPChangeRequestMessage_Sync element structure85000. Specifically, these figures depict the arrangement and hierarchyof various components such as one or more levels of packages, entities,and datatypes, shown here as 85000 through 85108. As described above,packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxReturnERPChangeRequestMessage_Sync elementstructure 85000 includes, among other things, MessageHeader 85006.Accordingly, heterogeneous applications may communicate using thisconsistent message configured as such.

Additionally, FIGS. 86-1 through 86-10 illustrate one example logicalconfiguration of TaxReturnERPChangeConfirmationMessage_Sync elementstructure 86000. Specifically, these figures depict the arrangement andhierarchy of various components such as one or more levels of packages,entities, and datatypes, shown here as 86000 through 86254. As describedabove, packages may be used to represent hierarchy levels. Entities arediscrete business elements that are used during a business transaction.Data types are used to type object entities and interfaces with astructure. For example, TaxReturnERPChangeConfirmationMessage_Syncelement structure 86000 includes, among other things, MessageHeader86006. Accordingly, heterogeneous applications may communicate usingthis consistent message configured as such.

In further detail, FIGS. 76-1 through 76-12 illustrate an exampleconfiguration of an Element Structure that includes aTaxReturnERPMessage_Sync 76000 package. The TaxReturnERPMessage_Sync76000 package is a TxRtrnERPMsg 76004 data type. TheTaxReturnERPMessage_Sync 76000 package includes aTaxReturnERPMessage_Sync 76002 entity. The TaxReturnERPMessage_Sync76000 package includes various packages, namely a MessageHeader 76006, aTaxReturn 76012, a ProcessingConditions 76268 and a Log 76278.

The MessageHeader 76006 package is a BasicBusinessDocumentMessageHeader76010 data type. The MessageHeader 76006 package includes aMessageHeader 76008 entity.

The TaxReturn 76012 package is a TxRtrn 76016 data type. The TaxReturn76012 package includes a TaxReturn 76014 entity. The TaxReturn 76012package includes various packages, namely a Form 76098, a TaxPayer76146, a TaxPreparer 76188 and a JointFiler 76230.

The TaxReturn 76014 entity includes various attributes, namely an@formListCompleteTransmissionIndicator 76018, a TaxReturnID 76022, aLevyTypeCode 76026, a LevyTypeCodeName 76030, a ContractAccountID 76034,a PeriodAssignmentCode 76038, a PeriodAssignmentCodeName 76042, aTaxObligationID 76046, a TaxAmount 76050, an InterestAmount 76054, anAdditionalReceivablesAmount 76058 and a DraftIndicator 76094. TheTaxReturn 76014 entity includes various subordinate entities, namely aSystemStatus 76062 and a UserStatus 76084. The@formListCompleteTransmissionIndicator 76018 attribute is an Indicator76020 data type. The TaxReturnID 76022 attribute is an Identifier 76024data type. TaxReturnID is a technical key of a carrying object.

The LevyTypeCode 76026 attribute is a Code 76028 data type. Code is acharacter string of letters, numbers, special characters (except escapesequences), and symbols. Code represents a definitive value, a method,or a property description in an abbreviated or language-independentform. The LevyTypeCodeName 76030 attribute is a MEDIUM_Name 76032 datatype. The ContractAccountID 76034 attribute is a ContractAccountID 76036data type. A ContractAccountID is a unique identifier for a contractaccount. The PeriodAssignmentCode 76038 attribute is a Code 76040 datatype. A code is a character string of letters, numbers, specialcharacters (except escape sequences), and symbols. A code represents adefinitive value, a method, or a property description in an abbreviatedor language-independent form. PeriodAssignmentCode is a key for periodassignment.

The PeriodAssignmentCodeName 76042 attribute is a MEDIUM_Name 76044 datatype. MEDIUM_Description is a restriction on GDT Description to specifya uniform length for descriptions of medium length. MEDIUM_Descriptioncontains the variable “MEDIUM_”, which gets replaced by one or morequalifiers. The TaxObligationID 76046 attribute is an Identifier 76048data type. The TaxAmount 76050 attribute is an Amount 76052 data type.The InterestAmount 76054 attribute is an Amount 76056 data type. TheAdditionalReceivablesAmount 76058 attribute is an Amount 76060 datatype. The DraftIndicator 76094 attribute is an Indicator 76096 datatype. The SystemStatus 76062 entity includes various attributes, namelya Code 76064, a CodeName 76068, an InactiveIndicator 76072, aChangeTimePoint 76076 and a ProcessorPartyInternalID 76080.

The Code 76064 attribute is a Code 76066 data type. The CodeName 76068attribute is a MEDIUM_Name 76070 data type. The InactiveIndicator 76072attribute is an Indicator 76074 data type. The ChangeTimePoint 76076attribute is a LOCALOFFSET_DateTime 76078 data type. TheProcessorPartyInternalID 76080 attribute is a PartyInternalID 76082 datatype. The UserStatus 76084 entity includes various attributes, namely aCode 76086 and a Name 76090. The Code 76086 attribute is a Code 76088data type. The Name 76090 attribute is a MEDIUM_Name 76092 data type.The Form 76098 package is a TxRtrnForm 76102 data type. The Form 76098package includes a Form 76100 entity. The Form 76098 package includes aPropertyValuation 76136 package.

The Form 76100 entity includes various attributes, namely an@propertyGroupListCompleteTransmissionIndicator 76104, an @actionCode76108, a FormUUID 76112, a VersionID 76116, a FormTemplateID 76120, aFormTemplateName 76124, a FormTypeCode 76128 and a FormTypeCodeName76132. The @propertyGroupListCompleteTransmissionIndicator 76104attribute is an Indicator 76106 data type. The @actionCode 76108attribute is an ActionCode 76110 data type. The FormUUID 76112 attributeis an UUID 76114 data type. The VersionID 76116 attribute is a VersionID76118 data type. The FormTemplateID 76120 attribute is anInternalServiceRequestTemplateID 76122 data type.InternalServiceRequestTemplateID is a unique identifier for an internalservice request template.

The FormTemplateName 76124 attribute is a MEDIUM_Name 76126 data type.MEDIUM_Description is a restriction on GDT Description to specify auniform length for descriptions of medium length. MEDIUM_Descriptionincludes the variable “MEDIUM_”, which gets replaced by one (or more)qualifier. The FormTypeCode 76128 attribute is a Code 76130 data type. ACode is a character string of letters, numbers, special characters(except escape sequences), and symbols. A Code represents a definitivevalue, a method, or a property description in an abbreviated orlanguage-independent form. FormTypeCode is a code for a form type. Oneform may be assigned to multiple form types.

The FormTypeCodeName 76132 attribute is a MEDIUM_Name 76134 data type.MEDIUM_Description is a restriction on GDT Description to specify auniform length for descriptions of medium length. MEDIUM_Descriptionincludes the variable “MEDIUM_”, which gets replaced by one or morequalifiers. The PropertyValuation 76136 package is a TxRtrnFormPrptyValn76140 data type. The PropertyValuation 76136 package includes aPropertyValuation 76138 entity. The PropertyValuation 76138 entityincludes a PropertyValuation 76142 attribute.

The PropertyValuation 76142 attribute is a PropertyValuation 76144 datatype. PropertyValuation is an assignment of one or more values to asimple or complex property. The TaxPayer 76146 package is a TxRtrnTxPyr76150 data type. The TaxPayer 76146 package includes a TaxPayer 76148entity. The TaxPayer 76148 entity includes a TaxPayerPartyID 76152attribute. The TaxPayer 76148 entity includes an Identification 76156subordinate entity. The TaxPayerPartyID 76152 attribute is aPartyInternalID 76154 data type.

The Identification 76156 entity includes various attributes, namely aPartyIdentifierTypeCode 76160, a PartyIdentifierID 76164, anIdentifierIssuingAgencyName 76168, an EntryDate 76172, anAreaOfValidityCountryCode 76176, an AreaOfValidityRegionCode 76180 and aValidityPeriod 76184. The PartyIdentifierTypeCode 76160 attribute is aPartyIdentifierTypeCode 76162 data type. The PartyIdentifierID 76164attribute is a PartyID 76166 data type. The IdentifierIssuingAgencyName76168 attribute is a LANGUAGEINDEPENDENT_MEDIUM_Name 76170 data type.The EntryDate 76172 attribute is a Date 76174 data type. TheAreaOfValidityCountryCode 76176 attribute is a CountryCode 76178 datatype. The AreaOfValidityRegionCode 76180 attribute is a RegionCode 76182data type.

The ValidityPeriod 76184 attribute is a CLOSED_DatePeriod 76186 datatype. The TaxPreparer 76188 package is a TxRtrnTxPrpr 76192 data type.The TaxPreparer 76188 package includes a TaxPreparer 76190 entity. TheTaxPreparer 76190 entity includes a TaxPreparerPartyID 76194 attribute.The TaxPreparer 76190 entity includes an Identification 76198subordinate entity. The TaxPreparerPartyID 76194 attribute is aPartyInternalID 76196 data type. The Identification 76198 entityincludes various attributes, namely a PartyIdentifierTypeCode 76202, aPartyIdentifierID 76206, an IdentifierIssuingAgencyName 76210, anEntryDate 76214, an AreaOfValidityCountryCode 76218, anAreaOfValidityRegionCode 76222 and a ValidityPeriod 76226.

The PartyIdentifierTypeCode 76202 attribute is a PartyIdentifierTypeCode76204 data type. The PartyIdentifierID 76206 attribute is a PartyID76208 data type. The IdentifierIssuingAgencyName 76210 attribute is aLANGUAGEINDEPENDENT_MEDIUM_Name 76212 data type. The EntryDate 76214attribute is a Date 76216 data type. The AreaOfValidityCountryCode 76218attribute is a CountryCode 76220 data type. The AreaOfValidityRegionCode76222 attribute is a RegionCode 76224 data type. The ValidityPeriod76226 attribute is a CLOSED_DatePeriod 76228 data type. The JointFiler76230 package includes a JointFiler 76232 entity. The JointFiler 76232entity includes a JointFilerPartyID 76234 attribute. The JointFiler76232 entity includes an Identification 76238 subordinate entity. TheJointFilerPartyID 76234 attribute is a PartyInternalID 76236 data type.A BusinessPartnerInternalID is a unique, proprietary identifier for abusiness partner.

The Identification 76238 entity includes various attributes, namely aPartyIdentifierTypeCode 76240, a PartyIdentifierID 76244, anIdentifierIssuingAgencyName 76248, an EntryDate 76252, anAreaOfValidityCountryCode 76256, an AreaOfValidityRegionCode 76260 and aValidityPeriod 76264. The PartyIdentifierTypeCode 76240 attribute is aPartyIdentifierTypeCode 76242 data type. The PartyIdentifierID 76244attribute is a PartyID 76246 data type. The IdentifierIssuingAgencyName76248 attribute is a LANGUAGEINDEPENDENT_MEDIUM_Name 76250 data type.The EntryDate 76252 attribute is a Date 76254 data type. TheAreaOfValidityCountryCode 76256 attribute is a CountryCode 76258 datatype. The AreaOfValidityRegionCode 76260 attribute is a RegionCode 76262data type. The ValidityPeriod 76264 attribute is a CLOSED_DatePeriod76266 data type.

The ProcessingConditions 76268 package is a QueryProcessingConditions76272 data type. The ProcessingConditions 76268 package includes variousentities, namely a QueryProcessingConditions 76270 and aResponseProcessingConditions 76274.

The Log 76278 package is a Log 76282 data type. The Log 76278 packageincludes a Log 76280 entity.

In further detail, FIGS. 77-1 through 77-9 illustrate an exampleconfiguration of an Element Structure that includes aTaxReturnERPByBusinessPartnerQueryMessage_Sync 77000 package. TheTaxReturnERPByBusinessPartnerQueryMessage_Sync 77000 package includes aTaxReturnERPByBusinessPartnerQueryMessage_Sync 77002 entity. TheTaxReturnERPByBusinessPartnerQueryMessage_Sync 77000 package includesvarious packages, namely a MessageHeader 77004, a Selection 77010 and aProcessingConditions 77218.

The MessageHeader 77004 package includes a MessageHeader 77006 entity.The MessageHeader 77006 entity has a cardinality of 1 77008 meaning thatfor each instance of the MessageHeader 77004 package there is oneMessageHeader 77006 entity.

The Selection 77010 package includes aTaxReturnSelectionByBusinessPartnerID 77012 entity. The Selection 77010package includes various packages, namely a SelectionByTaxPayerPartyID77016, a SelectionByTaxPayerPartyIdentifierID 77038, aSelectionByTaxPreparerPartyID 77064, aSelectionByTaxPreparerPartyIdentifierID 77086, aSelectionByJointFilerPartyID 77112, aSelectionByJointFilerPartyIdentifierID 77134, aSelectionByBillingPeriodID 77160, a SelectionByLevyTypeCode 77182 and aSelectionByDate 77204.

The TaxReturnSelectionByBusinessPartnerID 77012 entity has a cardinalityof 1 77014 meaning that for each instance of the Selection 77010 packagethere is one TaxReturnSelectionByBusinessPartnerID 77012 entity. TheSelectionByTaxPayerPartyID 77016 package includes aSelectionByTaxPayerPartyID 77018 entity. The SelectionByTaxPayerPartyID77018 entity has a cardinality of 0 . . . n 77020 meaning that for eachinstance of the SelectionByTaxPayerPartyID 77016 package there may beone or more SelectionByTaxPayerPartyID 77018 entities. TheSelectionByTaxPayerPartyID 77018 entity includes various attributes,namely an InclusionExclusionCode 77022, an IntervalBoundaryTypeCode77026, a LowerBoundaryTaxPayerPartyID 77030 and anUpperBoundaryTaxPayerPartyID 77034. The InclusionExclusionCode 77022attribute has a cardinality of 1 77024 meaning that for each instance ofthe SelectionByTaxPayerPartyID 77018 entity there is oneInclusionExclusionCode 77022 attribute. The IntervalBoundaryTypeCode77026 attribute has a cardinality of 1 77028 meaning that for eachinstance of the SelectionByTaxPayerPartyID 77018 entity there is oneIntervalBoundaryTypeCode 77026 attribute. TheLowerBoundaryTaxPayerPartyID 77030 attribute has a cardinality of 0 . .. 1 77032 meaning that for each instance of theSelectionByTaxPayerPartyID 77018 entity there may be oneLowerBoundaryTaxPayerPartyID 77030 attribute. TheUpperBoundaryTaxPayerPartyID 77034 attribute has a cardinality of 0 . .. 1 77036 meaning that for each instance of theSelectionByTaxPayerPartyID 77018 entity there may be oneUpperBoundaryTaxPayerPartyID 77034 attribute.

The SelectionByTaxPayerPartyIdentifierID 77038 package includes aSelectionByTaxPayerPartyIdentifierID 77040 entity. TheSelectionByTaxPayerPartyIdentifierID 77040 entity has a cardinality of 0. . . n 77042 meaning that for each instance of theSelectionByTaxPayerPartyIdentifierID 77038 package there may be one ormore SelectionByTaxPayerPartyIdentifierID 77040 entities. TheSelectionByTaxPayerPartyIdentifierID 77040 entity includes variousattributes, namely an InclusionExclusionCode 77044, anIntervalBoundaryTypeCode 77048, a LowerBoundaryPartyIdentifierID 77052,an UpperBoundaryPartyIdentifierID 77056 and a PartyIdentifierTypeCode77060. The InclusionExclusionCode 77044 attribute has a cardinality of 177046 meaning that for each instance of theSelectionByTaxPayerPartyIdentifierID 77040 entity there is oneInclusionExclusionCode 77044 attribute. The IntervalBoundaryTypeCode77048 attribute has a cardinality of 1 77050 meaning that for eachinstance of the SelectionByTaxPayerPartyIdentifierID 77040 entity thereis one IntervalBoundaryTypeCode 77048 attribute. TheLowerBoundaryPartyIdentifierID 77052 attribute has a cardinality of 0 .. . 1 77054 meaning that for each instance of theSelectionByTaxPayerPartyIdentifierID 77040 entity there may be oneLowerBoundaryPartyIdentifierID 77052 attribute. TheUpperBoundaryPartyIdentifierID 77056 attribute has a cardinality of 0 .. . 1 77058 meaning that for each instance of theSelectionByTaxPayerPartyIdentifierID 77040 entity there may be oneUpperBoundaryPartyIdentifierID 77056 attribute. ThePartyIdentifierTypeCode 77060 attribute has a cardinality of 1 77062meaning that for each instance of theSelectionByTaxPayerPartyIdentifierID 77040 entity there is onePartyIdentifierTypeCode 77060 attribute.

The SelectionByTaxPreparerPartyID 77064 package includes aSelectionByTaxPreparerPartyID 77066 entity. TheSelectionByTaxPreparerPartyID 77066 entity has a cardinality of 0 . . .n 77068 meaning that for each instance of theSelectionByTaxPreparerPartyID 77064 package there may be one or moreSelectionByTaxPreparerPartyID 77066 entities. TheSelectionByTaxPreparerPartyID 77066 entity includes various attributes,namely an InclusionExclusionCode 77070, an IntervalBoundaryTypeCode77074, a LowerBoundaryTaxPreparerPartyID 77078 and anUpperBoundaryTaxPreparerPartyID 77082. The InclusionExclusionCode 77070attribute has a cardinality of 1 77072 meaning that for each instance ofthe SelectionByTaxPreparerPartyID 77066 entity there is oneInclusionExclusionCode 77070 attribute. The IntervalBoundaryTypeCode77074 attribute has a cardinality of 1 77076 meaning that for eachinstance of the SelectionByTaxPreparerPartyID 77066 entity there is oneIntervalBoundaryTypeCode 77074 attribute. TheLowerBoundaryTaxPreparerPartyID 77078 attribute has a cardinality of 0 .. . 1 77080 meaning that for each instance of theSelectionByTaxPreparerPartyID 77066 entity there may be oneLowerBoundaryTaxPreparerPartyID 77078 attribute. TheUpperBoundaryTaxPreparerPartyID 77082 attribute has a cardinality of 0 .. . 1 77084 meaning that for each instance of theSelectionByTaxPreparerPartyID 77066 entity there may be oneUpperBoundaryTaxPreparerPartyID 77082 attribute.

The SelectionByTaxPreparerPartyIdentifierID 77086 package includes aSelectionByTaxPreparerPartyIdentifierID 77088 entity. TheSelectionByTaxPreparerPartyIdentifierID 77088 entity has a cardinalityof 0 . . . n 77090 meaning that for each instance of theSelectionByTaxPreparerPartyIdentifierID 77086 package there may be oneor more SelectionByTaxPreparerPartyIdentifierID 77088 entities. TheSelectionByTaxPreparerPartyIdentifierID 77088 entity includes variousattributes, namely an InclusionExclusionCode 77092, anIntervalBoundaryTypeCode 77096, a LowerBoundaryPartyIdentifierID 77100,an UpperBoundaryPartyIdentifierID 77104 and a PartyIdentifierTypeCode77108. The InclusionExclusionCode 77092 attribute has a cardinality of 177094 meaning that for each instance of theSelectionByTaxPreparerPartyIdentifierID 77088 entity there is oneInclusionExclusionCode 77092 attribute. The IntervalBoundaryTypeCode77096 attribute has a cardinality of 1 77098 meaning that for eachinstance of the SelectionByTaxPreparerPartyIdentifierID 77088 entitythere is one IntervalBoundaryTypeCode 77096 attribute.

The LowerBoundaryPartyIdentifierID 77100 attribute has a cardinality of0 . . . 1 77102 meaning that for each instance of theSelectionByTaxPreparerPartyIdentifierID 77088 entity there may be oneLowerBoundaryPartyIdentifierID 77100 attribute. TheUpperBoundaryPartyIdentifierID 77104 attribute has a cardinality of 0 .. . 1 77106 meaning that for each instance of theSelectionByTaxPreparerPartyIdentifierID 77088 entity there may be oneUpperBoundaryPartyIdentifierID 77104 attribute. ThePartyIdentifierTypeCode 77108 attribute has a cardinality of 1 77110meaning that for each instance of theSelectionByTaxPreparerPartyIdentifierID 77088 entity there is onePartyIdentifierTypeCode 77108 attribute.

The SelectionByJointFilerPartyID 77112 package includes aSelectionByJointFilerPartyID 77114 entity. TheSelectionByJointFilerPartyID 77114 entity has a cardinality of 0 . . . n77116 meaning that for each instance of the SelectionByJointFilerPartyID77112 package there may be one or more SelectionByJointFilerPartyID77114 entities. The SelectionByJointFilerPartyID 77114 entity includesvarious attributes, namely an InclusionExclusionCode 77118, anIntervalBoundaryTypeCode 77122, a LowerBoundaryJointFilerPartyID 77126and an UpperBoundaryJointFilerPartyID 77130. The InclusionExclusionCode77118 attribute has a cardinality of 1 77120 meaning that for eachinstance of the SelectionByJointFilerPartyID 77114 entity there is oneInclusionExclusionCode 77118 attribute. The IntervalBoundaryTypeCode77122 attribute has a cardinality of 1 77124 meaning that for eachinstance of the SelectionByJointFilerPartyID 77114 entity there is oneIntervalBoundaryTypeCode 77122 attribute. TheLowerBoundaryJointFilerPartyID 77126 attribute has a cardinality of 0 .. . 1 77128 meaning that for each instance of theSelectionByJointFilerPartyID 77114 entity there may be oneLowerBoundaryJointFilerPartyID 77126 attribute. TheUpperBoundaryJointFilerPartyID 77130 attribute has a cardinality of 0 .. . 1 77132 meaning that for each instance of theSelectionByJointFilerPartyID 77114 entity there may be oneUpperBoundaryJointFilerPartyID 77130 attribute.

The SelectionByJointFilerPartyIdentifierID 77134 package includes aSelectionByJointFilerPartyIdentifierID 77136 entity. TheSelectionByJointFilerPartyIdentifierID 77136 entity has a cardinality of0 . . . n 77138 meaning that for each instance of theSelectionByJointFilerPartyIdentifierID 77134 package there may be one ormore SelectionByJointFilerPartyIdentifierID 77136 entities. TheSelectionByJointFilerPartyIdentifierID 77136 entity includes variousattributes, namely an InclusionExclusionCode 77140, anIntervalBoundaryTypeCode 77144, a LowerBoundaryPartyIdentifierID 77148,an UpperBoundaryPartyIdentifierID 77152 and a PartyIdentifierTypeCode77156. The InclusionExclusionCode 77140 attribute has a cardinality of 177142 meaning that for each instance of theSelectionByJointFilerPartyIdentifierID 77136 entity there is oneInclusionExclusionCode 77140 attribute. The IntervalBoundaryTypeCode77144 attribute has a cardinality of 1 77146 meaning that for eachinstance of the SelectionByJointFilerPartyIdentifierID 77136 entitythere is one IntervalBoundaryTypeCode 77144 attribute. TheLowerBoundaryPartyIdentifierID 77148 attribute has a cardinality of 0 .. . 1 77150 meaning that for each instance of theSelectionByJointFilerPartyIdentifierID 77136 entity there may be oneLowerBoundaryPartyIdentifierID 77148 attribute. TheUpperBoundaryPartyIdentifierID 77152 attribute has a cardinality of 0 .. . 1 77154 meaning that for each instance of theSelectionByJointFilerPartyIdentifierID 77136 entity there may be oneUpperBoundaryPartyIdentifierID 77152 attribute. ThePartyIdentifierTypeCode 77156 attribute has a cardinality of 1 77158meaning that for each instance of theSelectionByJointFilerPartyIdentifierID 77136 entity there is onePartyIdentifierTypeCode 77156 attribute.

The SelectionByBillingPeriodID 77160 package includes aSelectionByBillingPeriodID 77162 entity. The SelectionByBillingPeriodID77162 entity has a cardinality of 0 . . . n 77164 meaning that for eachinstance of the SelectionByBillingPeriodID 77160 package there may beone or more SelectionByBillingPeriodID 77162 entities. TheSelectionByBillingPeriodID 77162 entity includes various attributes,namely an InclusionExclusionCode 77166, an IntervalBoundaryTypeCode77170, a LowerBoundaryBillingPeriodID 77174 and anUpperBoundaryBillingPeriodID 77178. The InclusionExclusionCode 77166attribute has a cardinality of 1 77168 meaning that for each instance ofthe SelectionByBillingPeriodID 77162 entity there is oneInclusionExclusionCode 77166 attribute. The IntervalBoundaryTypeCode77170 attribute has a cardinality of 1 77172 meaning that for eachinstance of the SelectionByBillingPeriodID 77162 entity there is oneIntervalBoundaryTypeCode 77170 attribute. TheLowerBoundaryBillingPeriodID 77174 attribute has a cardinality of 0 . .. 1 77176 meaning that for each instance of theSelectionByBillingPeriodID 77162 entity there may be oneLowerBoundaryBillingPeriodID 77174 attribute. TheUpperBoundaryBillingPeriodID 77178 attribute has a cardinality of 0 . .. 1 77180 meaning that for each instance of theSelectionByBillingPeriodID 77162 entity there may be oneUpperBoundaryBillingPeriodID 77178 attribute.

The SelectionByLevyTypeCode 77182 package includes aSelectionByLevyTypeCode 77184 entity. The SelectionByLevyTypeCode 77184entity has a cardinality of 0 . . . n 77186 meaning that for eachinstance of the SelectionByLevyTypeCode 77182 package there may be oneor more SelectionByLevyTypeCode 77184 entities. TheSelectionByLevyTypeCode 77184 entity includes various attributes, namelyan InclusionExclusionCode 77188, an IntervalBoundaryTypeCode 77192, aLowerBoundaryLevyTypeCode 77196 and an UpperBoundaryLevyTypeCodeID77200. The InclusionExclusionCode 77188 attribute has a cardinality of 177190 meaning that for each instance of the SelectionByLevyTypeCode77184 entity there is one InclusionExclusionCode 77188 attribute. TheIntervalBoundaryTypeCode 77192 attribute has a cardinality of 1 77194meaning that for each instance of the SelectionByLevyTypeCode 77184entity there is one IntervalBoundaryTypeCode 77192 attribute. TheLowerBoundaryLevyTypeCode 77196 attribute has a cardinality of 0 . . . 177198 meaning that for each instance of the SelectionByLevyTypeCode77184 entity there may be one LowerBoundaryLevyTypeCode 77196 attribute.The UpperBoundaryLevyTypeCodeID 77200 attribute has a cardinality of 0 .. . 1 77202 meaning that for each instance of theSelectionByLevyTypeCode 77184 entity there may be oneUpperBoundaryLevyTypeCodeID 77200 attribute.

The SelectionByDate 77204 package includes a SelectionByDate 77206entity. The SelectionByDate 77206 entity has a cardinality of 0 . . . 177208 meaning that for each instance of the SelectionByDate 77204package there may be one SelectionByDate 77206 entity. TheSelectionByDate 77206 entity includes various attributes, namely aLowerBoundaryDate 77210 and an UpperBoundaryDate 77214. TheLowerBoundaryDate 77210 attribute has a cardinality of 1 77212 meaningthat for each instance of the SelectionByDate 77206 entity there is oneLowerBoundaryDate 77210 attribute. The UpperBoundaryDate 77214 attributehas a cardinality of 0 . . . 1 77216 meaning that for each instance ofthe SelectionByDate 77206 entity there may be one UpperBoundaryDate77214 attribute.

The ProcessingConditions 77218 package includes aQueryProcessingConditions 77220 entity. The QueryProcessingConditions77220 entity has a cardinality of 0 . . . 1 77222 meaning that for eachinstance of the ProcessingConditions 77218 package there may be oneQueryProcessingConditions 77220 entity. The data types of the variouspackages, entities, and attributes are described with respect to FIG.76.

In further detail, FIGS. 78-1 through 78-3 illustrate an exampleconfiguration of an Element Structure that includes aTaxReturnERPByBusinessPartnerResponseMessage_Sync 78000 package. TheTaxReturnERPByBusinessPartnerResponseMessage_Sync 78000 package includesa TaxReturnERPByBusinessPartnerResponseMessage_Sync 78002 entity. TheTaxReturnERPByBusinessPartnerResponseMessage_Sync 78000 package includesvarious packages, namely a TaxReturn 78004 and a Log 78074.

The TaxReturn 78004 package includes a TaxReturn 78006 entity. TheTaxReturn 78006 entity has a cardinality of 0 . . . n 78008 meaning thatfor each instance of the TaxReturn 78004 package there may be one ormore TaxReturn 78006 entities. The TaxReturn 78006 entity includesvarious attributes, namely a TaxReturnID 78010, a LevyTypeCode 78014, aLevyTypeCodeName 78018, a PeriodAssignmentCode 78022, aPeriodAssignmentCodeName 78026, a ReceiptDateTime 78030 and aDraftIndicator 78070. The TaxReturn 78006 entity includes varioussubordinate entities, namely a SystemStatus 78034 and a UserStatus78058. The TaxReturnID 78010 attribute has a cardinality of 1 78012meaning that for each instance of the TaxReturn 78006 entity there isone TaxReturnID 78010 attribute. The LevyTypeCode 78014 attribute has acardinality of 1 78016 meaning that for each instance of the TaxReturn78006 entity there is one LevyTypeCode 78014 attribute. TheLevyTypeCodeName 78018 attribute has a cardinality of 0 . . . 1 78020meaning that for each instance of the TaxReturn 78006 entity there maybe one LevyTypeCodeName 78018 attribute. The PeriodAssignmentCode 78022attribute has a cardinality of 1 78024 meaning that for each instance ofthe TaxReturn 78006 entity there is one PeriodAssignmentCode 78022attribute. The PeriodAssignmentCodeName 78026 attribute has acardinality of 0 . . . 1 78028 meaning that for each instance of theTaxReturn 78006 entity there may be one PeriodAssignmentCodeName 78026attribute. The ReceiptDateTime 78030 attribute has a cardinality of 0 .. . 1 78032 meaning that for each instance of the TaxReturn 78006 entitythere may be one ReceiptDateTime 78030 attribute. The DraftIndicator78070 attribute has a cardinality of 1 78072 meaning that for eachinstance of the TaxReturn 78006 entity there is one DraftIndicator 78070attribute.

The SystemStatus 78034 entity has a cardinality of 1 . . . n 78036meaning that for each instance of the TaxReturn 78006 entity there areone or more SystemStatus 78034 entities. The SystemStatus 78034 entityincludes various attributes, namely a Code 78038, a CodeName 78042, anInactiveIndicator 78046, a ChangeTimePoint 78050 and aProcessorPartyInternalID 78054. The Code 78038 attribute has acardinality of 1 78040 meaning that for each instance of theSystemStatus 78034 entity there is one Code 78038 attribute. TheCodeName 78042 attribute has a cardinality of 0 . . . 1 78044 meaningthat for each instance of the SystemStatus 78034 entity there may be oneCodeName 78042 attribute. The InactiveIndicator 78046 attribute has acardinality of 1 78048 meaning that for each instance of theSystemStatus 78034 entity there is one InactiveIndicator 78046attribute. The ChangeTimePoint 78050 attribute has a cardinality of 178052 meaning that for each instance of the SystemStatus 78034 entitythere is one ChangeTimePoint 78050 attribute. TheProcessorPartyInternalID 78054 attribute has a cardinality of 1 78056meaning that for each instance of the SystemStatus 78034 entity there isone ProcessorPartyInternalID 78054 attribute.

The UserStatus 78058 entity has a cardinality of 0 . . . n 78060 meaningthat for each instance of the TaxReturn 78006 entity there may be one ormore UserStatus 78058 entities. The UserStatus 78058 entity includesvarious attributes, namely a Code 78062 and a Name 78066. The Code 78062attribute has a cardinality of 1 78064 meaning that for each instance ofthe UserStatus 78058 entity there is one Code 78062 attribute. The Name78066 attribute has a cardinality of 0 . . . 1 78068 meaning that foreach instance of the UserStatus 78058 entity there may be one Name 78066attribute.

The Log 78074 package includes a Log 78076 entity. The Log 78076 entityhas a cardinality of 1 78078 meaning that for each instance of the Log78074 package there is one Log 78076 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 76.

In further detail, FIG. 79 illustrates an example configuration of anElement Structure that includes a TaxReturnERPByIdQueryMessage_Sync79000 package. The TaxReturnERPByIdQueryMessage_Sync 79000 packageincludes a TaxReturnERPByIdQueryMessage_Sync 79002 entity. TheTaxReturnERPByIdQueryMessage_Sync 79000 package includes variouspackages, namely a MessageHeader 79004 and a Selection 79010.

The MessageHeader 79004 package includes a MessageHeader 79006 entity.The MessageHeader 79006 entity has a cardinality of 1 79008 meaning thatfor each instance of the MessageHeader 79004 package there is oneMessageHeader 79006 entity.

The Selection 79010 package includes a TaxReturnSelectionById 79012entity. The TaxReturnSelectionById 79012 entity has a cardinality of 179014 meaning that for each instance of the Selection 79010 packagethere is one TaxReturnSelectionById 79012 entity. TheTaxReturnSelectionById 79012 entity includes a TaxReturnID 79016attribute. The TaxReturnID 79016 attribute has a cardinality of 1 79018meaning that for each instance of the TaxReturnSelectionById 79012entity there is one TaxReturnID 79016 attribute. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 76.

In further detail, FIGS. 80-1 through 80-10 illustrate an exampleconfiguration of an Element Structure that includes aTaxReturnERPByIdResponseMessage_Sync 80000 package. TheTaxReturnERPByIdResponseMessage_Sync 80000 package includes aTaxReturnERPByIdResponseMessage_Sync 80002 entity. TheTaxReturnERPByIdResponseMessage_Sync 80000 package includes variouspackages, namely a TaxReturn 80004 and a Log 80244.

The TaxReturn 80004 package includes a TaxReturn 80006 entity. TheTaxReturn 80004 package includes various packages, namely a Form 80078,a TaxPayer 80118, a TaxPreparer 80160 and a JointFiler 80202.

The TaxReturn 80006 entity has a cardinality of 0 . . . 1 80008 meaningthat for each instance of the TaxReturn 80004 package there may be oneTaxReturn 80006 entity. The TaxReturn 80006 entity includes variousattributes, namely a TaxReturnID 80010, a LevyTypeCode 80014, aLevyTypeCodeName 80018, a ContractAccountID 80022, aPeriodAssignmentCode 80026, a PeriodAssignmentCodeName 80030, aTaxObligationID 80034 and a DraftIndicator 80074. The TaxReturn 80006entity includes various subordinate entities, namely a SystemStatus80038 and a UserStatus 80062. The TaxReturnID 80010 attribute has acardinality of 1 80012 meaning that for each instance of the TaxReturn80006 entity there is one TaxReturnID 80010 attribute. The LevyTypeCode80014 attribute has a cardinality of 1 80016 meaning that for eachinstance of the TaxReturn 80006 entity there is one LevyTypeCode 80014attribute. The LevyTypeCodeName 80018 attribute has a cardinality of 0 .. . 1 80020 meaning that for each instance of the TaxReturn 80006 entitythere may be one LevyTypeCodeName 80018 attribute. The ContractAccountID80022 attribute has a cardinality of 0 . . . 1 80024 meaning that foreach instance of the TaxReturn 80006 entity there may be oneContractAccountID 80022 attribute. The PeriodAssignmentCode 80026attribute has a cardinality of 1 80028 meaning that for each instance ofthe TaxReturn 80006 entity there is one PeriodAssignmentCode 80026attribute. The PeriodAssignmentCodeName 80030 attribute has acardinality of 0 . . . 1 80032 meaning that for each instance of theTaxReturn 80006 entity there may be one PeriodAssignmentCodeName 80030attribute. The TaxObligationID 80034 attribute has a cardinality of 180036 meaning that for each instance of the TaxReturn 80006 entity thereis one TaxObligationID 80034 attribute. The DraftIndicator 80074attribute has a cardinality of 1 80076 meaning that for each instance ofthe TaxReturn 80006 entity there is one DraftIndicator 80074 attribute.

The SystemStatus 80038 entity has a cardinality of 1 . . . n 80040meaning that for each instance of the TaxReturn 80006 entity there areone or more SystemStatus 80038 entities. The SystemStatus 80038 entityincludes various attributes, namely a Code 80042, a CodeName 80046, anInactiveIndicator 80050, a ChangeTimePoint 80054 and aProcessorPartyInternalID 80058. The Code 80042 attribute has acardinality of 1 80044 meaning that for each instance of theSystemStatus 80038 entity there is one Code 80042 attribute. TheCodeName 80046 attribute has a cardinality of 0 . . . 1 80048 meaningthat for each instance of the SystemStatus 80038 entity there may be oneCodeName 80046 attribute. The InactiveIndicator 80050 attribute has acardinality of 1 80052 meaning that for each instance of theSystemStatus 80038 entity there is one InactiveIndicator 80050attribute. The ChangeTimePoint 80054 attribute has a cardinality of 180056 meaning that for each instance of the SystemStatus 80038 entitythere is one ChangeTimePoint 80054 attribute. TheProcessorPartyInternalID 80058 attribute has a cardinality of 1 80060meaning that for each instance of the SystemStatus 80038 entity there isone ProcessorPartyInternalID 80058 attribute.

The UserStatus 80062 entity has a cardinality of 0 . . . n 80064 meaningthat for each instance of the TaxReturn 80006 entity there may be one ormore UserStatus 80062 entities. The UserStatus 80062 entity includesvarious attributes, namely a Code 80066 and a Name 80070. The Code 80066attribute has a cardinality of 1 80068 meaning that for each instance ofthe UserStatus 80062 entity there is one Code 80066 attribute. The Name80070 attribute has a cardinality of 0 . . . 1 80072 meaning that foreach instance of the UserStatus 80062 entity there may be one Name 80070attribute.

The Form 80078 package includes a Form 80080 entity. The Form 80078package includes a PropertyValuation 80108 package.

The Form 80080 entity has a cardinality of 1 . . . n 80082 meaning thatfor each instance of the Form 80078 package there are one or more Form80080 entities. The Form 80080 entity includes various attributes,namely a FormUUID 80084, a FormTemplateID 80088, a FormTemplateName80092, a FormVersionID 80096, a FormTypeCode 80100 and aFormTypeCodeName 80104. The FormUUID 80084 attribute has a cardinalityof 1 80086 meaning that for each instance of the Form 80080 entity thereis one FormUUID 80084 attribute. The FormTemplateID 80088 attribute hasa cardinality of 1 80090 meaning that for each instance of the Form80080 entity there is one FormTemplateID 80088 attribute. TheFormTemplateName 80092 attribute has a cardinality of 0 . . . 1 80094meaning that for each instance of the Form 80080 entity there may be oneFormTemplateName 80092 attribute. The FormVersionID 80096 attribute hasa cardinality of 1 80098 meaning that for each instance of the Form80080 entity there is one FormVersionID 80096 attribute. TheFormTypeCode 80100 attribute has a cardinality of 1 80102 meaning thatfor each instance of the Form 80080 entity there is one FormTypeCode80100 attribute. The FormTypeCodeName 80104 attribute has a cardinalityof 0 . . . 1 80106 meaning that for each instance of the Form 80080entity there may be one FormTypeCodeName 80104 attribute.

The PropertyValuation 80108 package includes a PropertyValuation 80110entity. The PropertyValuation 80110 entity has a cardinality of 0 . . .1 80112 meaning that for each instance of the PropertyValuation 80108package there may be one PropertyValuation 80110 entity. ThePropertyValuation 80110 entity includes a PropertyValuation 80114attribute. The PropertyValuation 80114 attribute has a cardinality of 1. . . n 80116 meaning that for each instance of the PropertyValuation80110 entity there are one or more PropertyValuation 80114 attributes.The TaxPayer 80118 package includes a TaxPayer 80120 entity. TheTaxPayer 80120 entity has a cardinality of 1 . . . 1 80122 meaning thatfor each instance of the TaxPayer 80118 package there is one instance ofthe TaxPayer 80120 entity. The TaxPayer 80120 entity includes aTaxPayerPartyID 80124 attribute. The TaxPayer 80120 entity includes anIdentification 80128 subordinate entity. The TaxPayerPartyID 80124attribute has a cardinality of 1 80126 meaning that for each instance ofthe TaxPayer 80120 entity there is one TaxPayerPartyID 80124 attribute.

The Identification 80128 entity has a cardinality of 0 . . . n 80130meaning that for each instance of the TaxPayer 80120 entity there may beone or more Identification 80128 entities. The Identification 80128entity includes various attributes, namely a PartyIdentifierTypeCode80132, a PartyIdentifierID 80136, an IdentifierIssuingAgencyName 80140,an EntryDate 80144, an AreaOfValidityCountryCode 80148, anAreaOfValidityRegionCode 80152 and a ValidityPeriod 80156. ThePartyIdentifierTypeCode 80132 attribute has a cardinality of 1 80134meaning that for each instance of the Identification 80128 entity thereis one PartyIdentifierTypeCode 80132 attribute. The PartyIdentifierID80136 attribute has a cardinality of 1 80138 meaning that for eachinstance of the Identification 80128 entity there is onePartyIdentifierID 80136 attribute. The IdentifierIssuingAgencyName 80140attribute has a cardinality of 0 . . . 1 80142 meaning that for eachinstance of the Identification 80128 entity there may be oneIdentifierIssuingAgencyName 80140 attribute. The EntryDate 80144attribute has a cardinality of 0 . . . 1 80146 meaning that for eachinstance of the Identification 80128 entity there may be one EntryDate80144 attribute. The AreaOfValidityCountryCode 80148 attribute has acardinality of 0 . . . 1 80150 meaning that for each instance of theIdentification 80128 entity there may be one AreaOfValidityCountryCode80148 attribute. The AreaOfValidityRegionCode 80152 attribute has acardinality of 0 . . . 1 80154 meaning that for each instance of theIdentification 80128 entity there may be one AreaOfValidityRegionCode80152 attribute. The ValidityPeriod 80156 attribute has a cardinality of0 . . . 1 80158 meaning that for each instance of the Identification80128 entity there may be one ValidityPeriod 80156 attribute.

The TaxPreparer 80160 package includes a TaxPreparer 80162 entity. TheTaxPreparer 80162 entity has a cardinality of 0 . . . 1 80164 meaningthat for each instance of the TaxPreparer 80160 package there may be oneTaxPreparer 80162 entity. The TaxPreparer 80162 entity includes aTaxPreparerPartyID 80166 attribute. The TaxPreparer 80162 entityincludes an Identification 80170 subordinate entity. TheTaxPreparerPartyID 80166 attribute has a cardinality of 1 80168 meaningthat for each instance of the TaxPreparer 80162 entity there is oneTaxPreparerPartyID 80166 attribute.

The Identification 80170 entity has a cardinality of 0 . . . n 80172meaning that for each instance of the TaxPreparer 80162 entity there maybe one or more Identification 80170 entities. The Identification 80170entity includes various attributes, namely a PartyIdentifierTypeCode80174, a PartyIdentifierID 80178, an IdentifierIssuingAgencyName 80182,an EntryDate 80186, an AreaOfValidityCountryCode 80190, anAreaOfValidityRegionCode 80194 and a ValidityPeriod 80198. ThePartyIdentifierTypeCode 80174 attribute has a cardinality of 1 80176meaning that for each instance of the Identification 80170 entity thereis one PartyIdentifierTypeCode 80174 attribute. The PartyIdentifierID80178 attribute has a cardinality of 1 80180 meaning that for eachinstance of the Identification 80170 entity there is onePartyIdentifierID 80178 attribute. The IdentifierIssuingAgencyName 80182attribute has a cardinality of 0 . . . 1 80184 meaning that for eachinstance of the Identification 80170 entity there may be oneIdentifierIssuingAgencyName 80182 attribute. The EntryDate 80186attribute has a cardinality of 0 . . . 1 80188 meaning that for eachinstance of the Identification 80170 entity there may be one EntryDate80186 attribute. The AreaOfValidityCountryCode 80190 attribute has acardinality of 0 . . . 1 80192 meaning that for each instance of theIdentification 80170 entity there may be one AreaOfValidityCountryCode80190 attribute. The AreaOfValidityRegionCode 80194 attribute has acardinality of 0 . . . 1 80196 meaning that for each instance of theIdentification 80170 entity there may be one AreaOfValidityRegionCode80194 attribute. The ValidityPeriod 80198 attribute has a cardinality of0 . . . 1 80200 meaning that for each instance of the Identification80170 entity there may be one ValidityPeriod 80198 attribute.

The JointFiler 80202 package includes a JointFiler 80204 entity. TheJointFiler 80204 entity has a cardinality of 0 . . . 1 80206 meaningthat for each instance of the JointFiler 80202 package there may be oneJointFiler 80204 entity. The JointFiler 80204 entity includes aJointFilerPartyID 80208 attribute. The JointFiler 80204 entity includesan Identification 80212 subordinate entity. The JointFilerPartyID 80208attribute has a cardinality of 1 80210 meaning that for each instance ofthe JointFiler 80204 entity there is one JointFilerPartyID 80208attribute.

The Identification 80212 entity has a cardinality of 0 . . . n 80214meaning that for each instance of the JointFiler 80204 entity there maybe one or more Identification 80212 entities.

The Identification 80212 entity includes various attributes, namely aPartyIdentifierTypeCode 80216, a PartyIdentifierID 80220, anIdentifierIssuingAgencyName 80224, an EntryDate 80228, anAreaOfValidityCountryCode 80232, an AreaOfValidityRegionCode 80236 and aValidityPeriod 80240. The PartyIdentifierTypeCode 80216 attribute has acardinality of 1 80218 meaning that for each instance of theIdentification 80212 entity there is one PartyIdentifierTypeCode 80216attribute. The PartyIdentifierID 80220 attribute has a cardinality of 180222 meaning that for each instance of the Identification 80212 entitythere is one PartyIdentifierID 80220 attribute. TheIdentifierIssuingAgencyName 80224 attribute has a cardinality of 0 . . .1 80226 meaning that for each instance of the Identification 80212entity there may be one IdentifierIssuingAgencyName 80224 attribute. TheEntryDate 80228 attribute has a cardinality of 0 . . . 1 80230 meaningthat for each instance of the Identification 80212 entity there may beone EntryDate 80228 attribute. The AreaOfValidityCountryCode 80232attribute has a cardinality of 0 . . . 1 80234 meaning that for eachinstance of the Identification 80212 entity there may be oneAreaOfValidityCountryCode 80232 attribute. The AreaOfValidityRegionCode80236 attribute has a cardinality of 0 . . . 1 80238 meaning that foreach instance of the Identification 80212 entity there may be oneAreaOfValidityRegionCode 80236 attribute. The ValidityPeriod 80240attribute has a cardinality of 0 . . . 1 80242 meaning that for eachinstance of the Identification 80212 entity there may be oneValidityPeriod 80240 attribute.

The Log 80244 package includes a Log 80246 entity. The Log 80246 entityhas a cardinality of 1 80248 meaning that for each instance of the Log80244 package there is one Log 80246 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 76.

In further detail, FIGS. 81-1 through 81-4 illustrate an exampleconfiguration of an Element Structure that includes aTaxReturnERPCreateRequestMessage_Sync 81000 package. TheTaxReturnERPCreateRequestMessage_Sync 81000 package includes aTaxReturnERPCreateRequestMessage_Sync 81002 entity. TheTaxReturnERPCreateRequestMessage_Sync 81000 package includes variouspackages, namely a MessageHeader 81004 and a TaxReturn 81010.

The MessageHeader 81004 package includes a MessageHeader 81006 entity.The MessageHeader 81006 entity has a cardinality of 1 81008 meaning thatfor each instance of the MessageHeader 81004 package there is oneMessageHeader 81006 entity.

The TaxReturn 81010 package includes a TaxReturn 81012 entity. TheTaxReturn 81010 package includes various packages, namely a Form 81036,a TaxPayer 81064, a TaxPreparer 81074 and a JointFiler 81084.

The TaxReturn 81012 entity has a cardinality of 1 81014 meaning that foreach instance of the TaxReturn 81010 package there is one TaxReturn81012 entity. The TaxReturn 81012 entity includes various attributes,namely a LevyTypeCode 81016, a ContractAccountID 81020, aPeriodAssignmentCode 81024, a TaxObligationID 81028 and a DraftIndicator81032. The LevyTypeCode 81016 attribute has a cardinality of 1 81018meaning that for each instance of the TaxReturn 81012 entity there isone LevyTypeCode 81016 attribute. The ContractAccountID 81020 attributehas a cardinality of 0 . . . 1 81022 meaning that for each instance ofthe TaxReturn 81012 entity there may be one ContractAccountID 81020attribute. The PeriodAssignmentCode 81024 attribute has a cardinality of1 81026 meaning that for each instance of the TaxReturn 81012 entitythere is one PeriodAssignmentCode 81024 attribute. The TaxObligationID81028 attribute has a cardinality of 1 81030 meaning that for eachinstance of the TaxReturn 81012 entity there is one TaxObligationID81028 attribute. The DraftIndicator 81032 attribute has a cardinality of0 . . . 1 81034 meaning that for each instance of the TaxReturn 81012entity there may be one DraftIndicator 81032 attribute.

The Form 81036 package includes a Form 81038 entity. The Form 81036package includes a PropertyValuation 81054 package.

The Form 81038 entity has a cardinality of 1 . . . n 81040 meaning thatfor each instance of the Form 81036 package there are one or more Form81038 entities. The Form 81038 entity includes various attributes,namely a FormUUID 81042, a FormTemplateID 81046 and a FormVersionID81050. The FormUUID 81042 attribute has a cardinality of 0 . . . 1 81044meaning that for each instance of the Form 81038 entity there may be oneFormUUID 81042 attribute. The FormTemplateID 81046 attribute has acardinality of 1 81048 meaning that for each instance of the Form 81038entity there is one FormTemplateID 81046 attribute. The FormVersionID81050 attribute has a cardinality of 1 81052 meaning that for eachinstance of the Form 81038 entity there is one FormVersionID 81050attribute.

The PropertyValuation 81054 package includes a PropertyValuation 81056entity. The PropertyValuation 81056 entity has a cardinality of 0 . . .1 81058 meaning that for each instance of the PropertyValuation 81054package there may be one PropertyValuation 81056 entity. ThePropertyValuation 81056 entity includes a PropertyValuation 81060attribute. The PropertyValuation 81060 attribute has a cardinality of 1. . . n 81062 meaning that for each instance of the PropertyValuation81056 entity there are one or more PropertyValuation 81060 attributes.

The TaxPayer 81064 package includes a TaxPayer 81066 entity. TheTaxPayer 81066 entity has a cardinality of 1 . . . 1 81068 meaning thatfor each instance of the TaxPayer 81064 package there is one TaxPayer81066 entity. The TaxPayer 81066 entity includes a TaxPayerPartyID 81070attribute. The TaxPayerPartyID 81070 attribute has a cardinality of 181072 meaning that for each instance of the TaxPayer 81066 entity thereis one TaxPayerPartyID 81070 attribute.

The TaxPreparer 81074 package includes a TaxPreparer 81076 entity. TheTaxPreparer 81076 entity has a cardinality of 0 . . . 1 81078 meaningthat for each instance of the TaxPreparer 81074 package there may be oneTaxPreparer 81076 entity. The TaxPreparer 81076 entity includes aTaxPreparerPartyID 81080 attribute. The TaxPreparerPartyID 81080attribute has a cardinality of 1 81082 meaning that for each instance ofthe TaxPreparer 81076 entity there is one TaxPreparerPartyID 81080attribute.

The JointFiler 81084 package includes a JointFiler 81086 entity. TheJointFiler 81086 entity has a cardinality of 0 . . . 1 81088 meaningthat for each instance of the JointFiler 81084 package there may be oneJointFiler 81086 entity. The JointFiler 81086 entity includes aJointFilerPartyID 81090 attribute. The JointFilerPartyID 81090 attributehas a cardinality of 1 81092 meaning that for each instance of theJointFiler 81086 entity there is one JointFilerPartyID 81090 attribute.The data types of the various packages, entities, and attributes aredescribed with respect to FIG. 76.

In further detail, FIGS. 82-1 through 82-10 illustrate an exampleconfiguration of an Element Structure that includes aTaxReturnERPCreateConfirmationMessage_Sync 82000 package. TheTaxReturnERPCreateConfirmationMessage_Sync 82000 package includes aTaxReturnERPCreateConfirmationMessage_Sync 82002 entity. TheTaxReturnERPCreateConfirmationMessage_Sync 82000 package includesvarious packages, namely a MessageHeader 82004, a TaxReturn 82010 and aLog 82250.

The MessageHeader 82004 package includes a MessageHeader 82006 entity.The MessageHeader 82006 entity has a cardinality of 0 . . . 1 82008meaning that for each instance of the MessageHeader 82004 package theremay be one MessageHeader 82006 entity.

The TaxReturn 82010 package includes a TaxReturn 82012 entity. TheTaxReturn 82010 package includes various packages, namely a Form 82084,a TaxPayer 82124, a TaxPreparer 82166 and a JointFiler 82208.

The TaxReturn 82012 entity has a cardinality of 1 82014 meaning that foreach instance of the TaxReturn 82010 package there is one TaxReturn82012 entity. The TaxReturn 82012 entity includes various attributes,namely a TaxReturnID 82016, a LevyTypeCode 82020, a LevyTypeCodeName82024, a ContractAccountID 82028, a PeriodAssignmentCode 82032, aPeriodAssignmentCodeName 82036, a TaxObligationID 82040 and aDraftIndicator 82080. The TaxReturn 82012 entity includes varioussubordinate entities, namely a SystemStatus 82044 and a UserStatus82068. The TaxReturnID 82016 attribute has a cardinality of 1 82018meaning that for each instance of the TaxReturn 82012 entity there isone TaxReturnID 82016 attribute. The LevyTypeCode 82020 attribute has acardinality of 1 82022 meaning that for each instance of the TaxReturn82012 entity there is one LevyTypeCode 82020 attribute. TheLevyTypeCodeName 82024 attribute has a cardinality of 0 . . . 1 82026meaning that for each instance of the TaxReturn 82012 entity there maybe one LevyTypeCodeName 82024 attribute. The ContractAccountID 82028attribute has a cardinality of 0 . . . 1 82030 meaning that for eachinstance of the TaxReturn 82012 entity there may be oneContractAccountID 82028 attribute. The PeriodAssignmentCode 82032attribute has a cardinality of 1 82034 meaning that for each instance ofthe TaxReturn 82012 entity there is one PeriodAssignmentCode 82032attribute. The PeriodAssignmentCodeName 82036 attribute has acardinality of 0 . . . 1 82038 meaning that for each instance of theTaxReturn 82012 entity there may be one PeriodAssignmentCodeName 82036attribute. The TaxObligationID 82040 attribute has a cardinality of 182042 meaning that for each instance of the TaxReturn 82012 entity thereis one TaxObligationID 82040 attribute. The DraftIndicator 82080attribute has a cardinality of 1 82082 meaning that for each instance ofthe TaxReturn 82012 entity there is one DraftIndicator 82080 attribute.

The SystemStatus 82044 entity has a cardinality of 1 . . . n 82046meaning that for each instance of the TaxReturn 82012 entity there areone or more SystemStatus 82044 entities. The SystemStatus 82044 entityincludes various attributes, namely a Code 82048, a Name 82052, anInactiveIndicator 82056, a ChangeTimePoint 82060 and aProcessorPartyInternalID 82064. The Code 82048 attribute has acardinality of 1 82050 meaning that for each instance of theSystemStatus 82044 entity there is one Code 82048 attribute. The Name82052 attribute has a cardinality of 0 . . . 1 82054 meaning that foreach instance of the SystemStatus 82044 entity there may be one Name82052 attribute. The InactiveIndicator 82056 attribute has a cardinalityof 1 82058 meaning that for each instance of the SystemStatus 82044entity there is one InactiveIndicator 82056 attribute. TheChangeTimePoint 82060 attribute has a cardinality of 1 82062 meaningthat for each instance of the SystemStatus 82044 entity there is oneChangeTimePoint 82060 attribute. The ProcessorPartyInternalID 82064attribute has a cardinality of 1 82066 meaning that for each instance ofthe SystemStatus 82044 entity there is one ProcessorPartyInternalID82064 attribute.

The UserStatus 82068 entity has a cardinality of 0 . . . n 82070 meaningthat for each instance of the TaxReturn 82012 entity there may be one ormore UserStatus 82068 entities. The UserStatus 82068 entity includesvarious attributes, namely a Code 82072 and a Name 82076. The Code 82072attribute has a cardinality of 1 82074 meaning that for each instance ofthe UserStatus 82068 entity there is one Code 82072 attribute. The Name82076 attribute has a cardinality of 0 . . . 1 82078 meaning that foreach instance of the UserStatus 82068 entity there may be one Name 82076attribute.

The Form 82084 package includes a Form 82086 entity. The Form 82084package includes a PropertyValuation 82114 package.

The Form 82086 entity has a cardinality of 1 . . . n 82088 meaning thatfor each instance of the Form 82084 package there are one or more Form82086 entities. The Form 82086 entity includes various attributes,namely a FormUUID 82090, a FormTemplateID 82094, a FormTemplateName82098, a FormVersionID 82102, a FormTypeCode 82106 and aFormTypeCodeName 82110. The FormUUID 82090 attribute has a cardinalityof 1 82092 meaning that for each instance of the Form 82086 entity thereis one FormUUID 82090 attribute. The FormTemplateID 82094 attribute hasa cardinality of 1 82096 meaning that for each instance of the Form82086 entity there is one FormTemplateID 82094 attribute. TheFormTemplateName 82098 attribute has a cardinality of 0 . . . 1 82100meaning that for each instance of the Form 82086 entity there may be oneFormTemplateName 82098 attribute. The FormVersionID 82102 attribute hasa cardinality of 1 82104 meaning that for each instance of the Form82086 entity there is one FormVersionID 82102 attribute. TheFormTypeCode 82106 attribute has a cardinality of 1 82108 meaning thatfor each instance of the Form 82086 entity there is one FormTypeCode82106 attribute. The FormTypeCodeName 82110 attribute has a cardinalityof 0 . . . 1 82112 meaning that for each instance of the Form 82086entity there may be one FormTypeCodeName 82110 attribute.

The PropertyValuation 82114 package includes a PropertyValuation 82116entity. The PropertyValuation 82116 entity has a cardinality of 0 . . .1 82118 meaning that for each instance of the PropertyValuation 82114package there may be one PropertyValuation 82116 entity. ThePropertyValuation 82116 entity includes a PropertyValuation 82120attribute. The PropertyValuation 82120 attribute has a cardinality of 1. . . n 82122 meaning that for each instance of the PropertyValuation82116 entity there are one or more PropertyValuation 82120 attributes.

The TaxPayer 82124 package includes a TaxPayer 82126 entity. TheTaxPayer 82126 entity has a cardinality of 1 . . . 1 82128 meaning thatfor each instance of the TaxPayer 82124 package there is one TaxPayer82126 entity. The TaxPayer 82126 entity includes a TaxPayerPartyID 82130attribute. The TaxPayer 82126 entity includes an Identification 82134subordinate entity. The TaxPayerPartyID 82130 attribute has acardinality of 1 82132 meaning that for each instance of the TaxPayer82126 entity there is one TaxPayerPartyID 82130 attribute.

The Identification 82134 entity has a cardinality of 0 . . . n 82136meaning that for each instance of the TaxPayer 82126 entity there may beone or more Identification 82134 entities. The Identification 82134entity includes various attributes, namely a PartyIdentifierTypeCode82138, a PartyIdentifierID 82142, an IdentifierIssuingAgencyName 82146,an EntryDate 82150, an AreaOfValidityCountryCode 82154, anAreaOfValidityRegionCode 82158 and a ValidityPeriod 82162. ThePartyIdentifierTypeCode 82138 attribute has a cardinality of 1 82140meaning that for each instance of the Identification 82134 entity thereis one PartyIdentifierTypeCode 82138 attribute. The PartyIdentifierID82142 attribute has a cardinality of 1 82144 meaning that for eachinstance of the Identification 82134 entity there is onePartyIdentifierID 82142 attribute. The IdentifierIssuingAgencyName 82146attribute has a cardinality of 0 . . . 1 82148 meaning that for eachinstance of the Identification 82134 entity there may be oneIdentifierIssuingAgencyName 82146 attribute. The EntryDate 82150attribute has a cardinality of 0 . . . 1 82152 meaning that for eachinstance of the Identification 82134 entity there may be one EntryDate82150 attribute. The AreaOfValidityCountryCode 82154 attribute has acardinality of 0 . . . 1 82156 meaning that for each instance of theIdentification 82134 entity there may be one AreaOfValidityCountryCode82154 attribute. The AreaOfValidityRegionCode 82158 attribute has acardinality of 0 . . . 1 82160 meaning that for each instance of theIdentification 82134 entity there may be one AreaOfValidityRegionCode82158 attribute. The ValidityPeriod 82162 attribute has a cardinality of0 . . . 1 82164 meaning that for each instance of the Identification82134 entity there may be one ValidityPeriod 82162 attribute.

The TaxPreparer 82166 package includes a TaxPreparer 82168 entity. TheTaxPreparer 82168 entity has a cardinality of 0 . . . 1 82170 meaningthat for each instance of the TaxPreparer 82166 package there may be oneTaxPreparer 82168 entity. The TaxPreparer 82168 entity includes aTaxPreparerPartyID 82172 attribute. The TaxPreparer 82168 entityincludes an Identification 82176 subordinate entity. TheTaxPreparerPartyID 82172 attribute has a cardinality of 1 82174 meaningthat for each instance of the TaxPreparer 82168 entity there is oneTaxPreparerPartyID 82172 attribute.

The Identification 82176 entity has a cardinality of 0 . . . n 82178meaning that for each instance of the TaxPreparer 82168 entity there maybe one or more Identification 82176 entities. The Identification 82176entity includes various attributes, namely a PartyIdentifierTypeCode82180, a PartyIdentifierID 82184, an IdentifierIssuingAgencyName 82188,an EntryDate 82192, an AreaOfValidityCountryCode 82196, anAreaOfValidityRegionCode 82200 and a ValidityPeriod 82204. ThePartyIdentifierTypeCode 82180 attribute has a cardinality of 1 82182meaning that for each instance of the Identification 82176 entity thereis one PartyIdentifierTypeCode 82180 attribute. The PartyIdentifierID82184 attribute has a cardinality of 1 82186 meaning that for eachinstance of the Identification 82176 entity there is onePartyIdentifierID 82184 attribute. The IdentifierIssuingAgencyName 82188attribute has a cardinality of 0 . . . 1 82190 meaning that for eachinstance of the Identification 82176 entity there may be oneIdentifierIssuingAgencyName 82188 attribute. The EntryDate 82192attribute has a cardinality of 0 . . . 1 82194 meaning that for eachinstance of the Identification 82176 entity there may be one EntryDate82192 attribute. The AreaOfValidityCountryCode 82196 attribute has acardinality of 0 . . . 1 82198 meaning that for each instance of theIdentification 82176 entity there may be one AreaOfValidityCountryCode82196 attribute. The AreaOfValidityRegionCode 82200 attribute has acardinality of 0 . . . 1 82202 meaning that for each instance of theIdentification 82176 entity there may be one AreaOfValidityRegionCode82200 attribute. The ValidityPeriod 82204 attribute has a cardinality of0 . . . 1 82206 meaning that for each instance of the Identification82176 entity there may be one ValidityPeriod 82204 attribute.

The JointFiler 82208 package includes a JointFiler 82210 entity. TheJointFiler 82210 entity has a cardinality of 0 . . . 1 82212 meaningthat for each instance of the JointFiler 82208 package there may be oneJointFiler 82210 entity. The JointFiler 82210 entity includes aJointFilerPartyID 82214 attribute. The JointFiler 82210 entity includesan Identification 82218 subordinate entity. The JointFilerPartyID 82214attribute has a cardinality of 1 82216 meaning that for each instance ofthe JointFiler 82210 entity there is one JointFilerPartyID 82214attribute.

The Identification 82218 entity has a cardinality of 0 . . . n 82220meaning that for each instance of the JointFiler 82210 entity there maybe one or more Identification 82218 entities. The Identification 82218entity includes various attributes, namely a PartyIdentifierTypeCode82222, a PartyIdentifierID 82226, an IdentifierIssuingAgencyName 82230,an EntryDate 82234, an AreaOfValidityCountryCode 82238, anAreaOfValidityRegionCode 82242 and a ValidityPeriod 82246. ThePartyIdentifierTypeCode 82222 attribute has a cardinality of 1 82224meaning that for each instance of the Identification 82218 entity thereis one PartyIdentifierTypeCode 82222 attribute. The PartyIdentifierID82226 attribute has a cardinality of 1 82228 meaning that for eachinstance of the Identification 82218 entity there is onePartyIdentifierID 82226 attribute. The IdentifierIssuingAgencyName 82230attribute has a cardinality of 0 . . . 1 82232 meaning that for eachinstance of the Identification 82218 entity there may be oneIdentifierIssuingAgencyName 82230 attribute. The EntryDate 82234attribute has a cardinality of 0 . . . 1 82236 meaning that for eachinstance of the Identification 82218 entity there may be one EntryDate82234 attribute. The AreaOfValidityCountryCode 82238 attribute has acardinality of 0 . . . 1 82240 meaning that for each instance of theIdentification 82218 entity there may be one AreaOfValidityCountryCode82238 attribute. The AreaOfValidityRegionCode 82242 attribute has acardinality of 0 . . . 1 82244 meaning that for each instance of theIdentification 82218 entity there may be one AreaOfValidityRegionCode82242 attribute. The ValidityPeriod 82246 attribute has a cardinality of0 . . . 1 82248 meaning that for each instance of the Identification82218 entity there may be one ValidityPeriod 82246 attribute.

The Log 82250 package includes a Log 82252 entity. The Log 82252 entityhas a cardinality of 1 82254 meaning that for each instance of the Log82250 package there is one Log 82252 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 76.

In further detail, FIGS. 83-1 through 83-3 illustrate an exampleconfiguration of an Element Structure that includes aTaxReturnERPValidateRequestMessage_Sync 83000 package. TheTaxReturnERPValidateRequestMessage_Sync 83000 package includes aTaxReturnERPValidateRequestMessage_Sync 83002 entity. TheTaxReturnERPValidateRequestMessage_Sync 83000 package includes variouspackages, namely a MessageHeader 83004 and a TaxReturn 83010.

The MessageHeader 83004 package includes a MessageHeader 83006 entity.The MessageHeader 83006 entity has a cardinality of 1 83008 meaning thatfor each instance of the MessageHeader 83004 package there is oneMessageHeader 83006 entity.

The TaxReturn 83010 package includes a TaxReturn 83012 entity. TheTaxReturn 83010 package includes various packages, namely a Form 83036,a TaxPayer 83064, a TaxPreparer 83074 and a JointFiler 83084.

The TaxReturn 83012 entity has a cardinality of 1 83014 meaning that foreach instance of the TaxReturn 83010 package there is one TaxReturn83012 entity. The TaxReturn 83012 entity includes various attributes,namely a TaxReturnID 83016, a LevyTypeCode 83020, a ContractAccountID83024, a PeriodAssignmentCode 83028 and a TaxObligationID 83032. TheTaxReturnID 83016 attribute has a cardinality of 0 . . . 1 83018 meaningthat for each instance of the TaxReturn 83012 entity there may be oneTaxReturnID 83016 attribute. The LevyTypeCode 83020 attribute has acardinality of 1 83022 meaning that for each instance of the TaxReturn83012 entity there is one LevyTypeCode 83020 attribute. TheContractAccountID 83024 attribute has a cardinality of 0 . . . 1 83026meaning that for each instance of the TaxReturn 83012 entity there maybe one ContractAccountID 83024 attribute. The PeriodAssignmentCode 83028attribute has a cardinality of 0 . . . 1 83030 meaning that for eachinstance of the TaxReturn 83012 entity there may be onePeriodAssignmentCode 83028 attribute. The TaxObligationID 83032attribute has a cardinality of 1 83034 meaning that for each instance ofthe TaxReturn 83012 entity there is one TaxObligationID 83032 attribute.

The Form 83036 package includes a Form 83038 entity. The Form 83036package includes a PropertyValuation 83054 package.

The Form 83038 entity has a cardinality of 1 . . . n 83040 meaning thatfor each instance of the Form 83036 package there are one or more Form83038 entities. The Form 83038 entity includes various attributes,namely a FormUUID 83042, a FormTemplateID 83046 and a FormVersionID83050. The FormUUID 83042 attribute has a cardinality of 0 . . . 1 83044meaning that for each instance of the Form 83038 entity there may be oneFormUUID 83042 attribute. The FormTemplateID 83046 attribute has acardinality of 1 83048 meaning that for each instance of the Form 83038entity there is one FormTemplateID 83046 attribute. The FormVersionID83050 attribute has a cardinality of 1 83052 meaning that for eachinstance of the Form 83038 entity there is one FormVersionID 83050attribute.

The PropertyValuation 83054 package includes a PropertyValuation 83056entity. The PropertyValuation 83056 entity has a cardinality of 0 . . .1 83058 meaning that for each instance of the PropertyValuation 83054package there may be one PropertyValuation 83056 entity. ThePropertyValuation 83056 entity includes a PropertyValuation 83060attribute. The PropertyValuation 83060 attribute has a cardinality of 1. . . n 83062 meaning that for each instance of the PropertyValuation83056 entity there are one or more PropertyValuation 83060 attributes.

The TaxPayer 83064 package includes a TaxPayer 83066 entity. TheTaxPayer 83066 entity has a cardinality of 1 . . . 1 83068 meaning thatfor each instance of the TaxPayer 83064 package there is one TaxPayer83066 entity and for each TaxPayer 83066 entity there is one TaxPayer83064 package. The TaxPayer 83066 entity includes a TaxPayerPartyID83070 attribute. The TaxPayerPartyID 83070 attribute has a cardinalityof 1 83072 meaning that for each instance of the TaxPayer 83066 entitythere is one TaxPayerPartyID 83070 attribute.

The TaxPreparer 83074 package includes a TaxPreparer 83076 entity. TheTaxPreparer 83076 entity has a cardinality of 0 . . . 1 83078 meaningthat for each instance of the TaxPreparer 83074 package there may be oneTaxPreparer 83076 entity. The TaxPreparer 83076 entity includes aTaxPreparerPartyID 83080 attribute. The TaxPreparerPartyID 83080attribute has a cardinality of 1 83082 meaning that for each instance ofthe TaxPreparer 83076 entity there is one TaxPreparerPartyID 83080attribute.

The JointFiler 83084 package includes a JointFiler 83086 entity. TheJointFiler 83086 entity has a cardinality of 0 . . . 1 83088 meaningthat for each instance of the JointFiler 83084 package there may be oneJointFiler 83086 entity. The JointFiler 83086 entity includes aJointFilerPartyID 83090 attribute. The JointFilerPartyID 83090 attributehas a cardinality of 1 83092 meaning that for each instance of theJointFiler 83086 entity there is one JointFilerPartyID 83090 attribute.The data types of the various packages, entities, and attributes aredescribed with respect to FIG. 76.

In further detail, FIGS. 84-1 through 84-10 illustrate an exampleconfiguration of an Element Structure that includes aTaxReturnERPValidateConfirmationMessage_Sync 84000 package. TheTaxReturnERPValidateConfirmationMessage_Sync 84000 package includes aTaxReturnERPValidateConfirmationMessage_Sync 84002 entity. TheTaxReturnERPValidateConfirmationMessage_Sync 84000 package includesvarious packages, namely a TaxReturn 84004 and a Log 84256.

The TaxReturn 84004 package includes a TaxReturn 84006 entity. TheTaxReturn 84004 package includes various packages, namely a Form 84090,a TaxPayer 84130, a TaxPreparer 84172 and a JointFiler 84214.

The TaxReturn 84006 entity has a cardinality of 0 . . . 1 84008 meaningthat for each instance of the TaxReturn 84004 package there may be oneTaxReturn 84006 entity. The TaxReturn 84006 entity includes variousattributes, namely a TaxReturnID 84010, a LevyTypeCode 84014, aLevyTypeCodeName 84018, a ContractAccountID 84022, aPeriodAssignmentCode 84026, a PeriodAssignmentCodeName 84030, aTaxObligationID 84034, a TaxAmount 84038, an InterestAmount 84042, anAdditionalReceivablesAmount 84046 and a DraftIndicator 84086. TheTaxReturn 84006 entity includes various subordinate entities, namely aSystemStatus 84050 and a UserStatus 84074. The TaxReturnID 84010attribute has a cardinality of 0 . . . 1 84012 meaning that for eachinstance of the TaxReturn 84006 entity there may be one TaxReturnID84010 attribute. The LevyTypeCode 84014 attribute has a cardinality of 184016 meaning that for each instance of the TaxReturn 84006 entity thereis one LevyTypeCode 84014 attribute. The LevyTypeCodeName 84018attribute has a cardinality of 0 . . . 1 84020 meaning that for eachinstance of the TaxReturn 84006 entity there may be one LevyTypeCodeName84018 attribute.

The ContractAccountID 84022 attribute has a cardinality of 0 . . . 184024 meaning that for each instance of the TaxReturn 84006 entity theremay be one ContractAccountID 84022 attribute. The PeriodAssignmentCode84026 attribute has a cardinality of 0 . . . 1 84028 meaning that foreach instance of the TaxReturn 84006 entity there may be onePeriodAssignmentCode 84026 attribute. The PeriodAssignmentCodeName 84030attribute has a cardinality of 0 . . . 1 84032 meaning that for eachinstance of the TaxReturn 84006 entity there may be onePeriodAssignmentCodeName 84030 attribute. The TaxObligationID 84034attribute has a cardinality of 1 84036 meaning that for each instance ofthe TaxReturn 84006 entity there is one TaxObligationID 84034 attribute.The TaxAmount 84038 attribute has a cardinality of 0 . . . 1 84040meaning that for each instance of the TaxReturn 84006 entity there maybe one TaxAmount 84038 attribute. The InterestAmount 84042 attribute hasa cardinality of 0 . . . 1 84044 meaning that for each instance of theTaxReturn 84006 entity there may be one InterestAmount 84042 attribute.The AdditionalReceivablesAmount 84046 attribute has a cardinality of 0 .. . 1 84048 meaning that for each instance of the TaxReturn 84006 entitythere may be one AdditionalReceivablesAmount 84046 attribute. TheDraftIndicator 84086 attribute has a cardinality of 1 84088 meaning thatfor each instance of the TaxReturn 84006 entity there is oneDraftIndicator 84086 attribute.

The SystemStatus 84050 entity has a cardinality of 1 . . . n 84052meaning that for each instance of the TaxReturn 84006 entity there areone or more SystemStatus 84050 entities. The SystemStatus 84050 entityincludes various attributes, namely a SystemStatusCode 84054, aSystemStatusCodeName 84058, an InactiveIndicator 84062, aChangeTimePoint 84066 and a ProcessorPartyInternalID 84070. TheSystemStatusCode 84054 attribute has a cardinality of 1 84056 meaningthat for each instance of the SystemStatus 84050 entity there is oneSystemStatusCode 84054 attribute. The SystemStatusCodeName 84058attribute has a cardinality of 0 . . . 1 84060 meaning that for eachinstance of the SystemStatus 84050 entity there may be oneSystemStatusCodeName 84058 attribute. The InactiveIndicator 84062attribute has a cardinality of 1 84064 meaning that for each instance ofthe SystemStatus 84050 entity there is one InactiveIndicator 84062attribute. The ChangeTimePoint 84066 attribute has a cardinality of 184068 meaning that for each instance of the SystemStatus 84050 entitythere is one ChangeTimePoint 84066 attribute. TheProcessorPartyInternalID 84070 attribute has a cardinality of 1 84072meaning that for each instance of the SystemStatus 84050 entity there isone ProcessorPartyInternalID 84070 attribute.

The UserStatus 84074 entity has a cardinality of 0 . . . n 84076 meaningthat for each instance of the TaxReturn 84006 entity there may be one ormore UserStatus 84074 entities. The UserStatus 84074 entity includesvarious attributes, namely a UserStatusCode 84078 and aUserStatusCodeName 84082. The UserStatusCode 84078 attribute has acardinality of 1 84080 meaning that for each instance of the UserStatus84074 entity there is one UserStatusCode 84078 attribute. TheUserStatusCodeName 84082 attribute has a cardinality of 0 . . . 1 84084meaning that for each instance of the UserStatus 84074 entity there maybe one UserStatusCodeName 84082 attribute.

The Form 84090 package includes a Form 84092 entity. The Form 84090package includes a PropertyValuation 84120 package.

The Form 84092 entity has a cardinality of 1 . . . n 84094 meaning thatfor each instance of the Form 84090 package there are one or more Form84092 entities. The Form 84092 entity includes various attributes,namely a FormUUID 84096, a FormTemplateID 84100, a FormTemplateName84104, a FormVersionID 84108, a FormTypeCode 84112 and aFormTypeCodeName 84116. The FormUUID 84096 attribute has a cardinalityof 0 . . . 1 84098 meaning that for each instance of the Form 84092entity there may be one FormUUID 84096 attribute. The FormTemplateID84100 attribute has a cardinality of 1 84102 meaning that for eachinstance of the Form 84092 entity there is one FormTemplateID 84100attribute. The FormTemplateName 84104 attribute has a cardinality of 0 .. . 1 84106 meaning that for each instance of the Form 84092 entitythere may be one FormTemplateName 84104 attribute. The FormVersionID84108 attribute has a cardinality of 1 84110 meaning that for eachinstance of the Form 84092 entity there is one FormVersionID 84108attribute. The FormTypeCode 84112 attribute has a cardinality of 1 84114meaning that for each instance of the Form 84092 entity there is oneFormTypeCode 84112 attribute. The FormTypeCodeName 84116 attribute has acardinality of 0 . . . 1 84118 meaning that for each instance of theForm 84092 entity there may be one FormTypeCodeName 84116 attribute.

The PropertyValuation 84120 package includes a PropertyValuation 84122entity. The PropertyValuation 84122 entity has a cardinality of 0 . . .1 84124 meaning that for each instance of the PropertyValuation 84120package there may be one PropertyValuation 84122 entity. ThePropertyValuation 84122 entity includes a PropertyValuation 84126attribute. The PropertyValuation 84126 attribute has a cardinality of 1. . . n 84128 meaning that for each instance of the PropertyValuation84122 entity there are one or more PropertyValuation 84126 attributes.

The TaxPayer 84130 package includes a TaxPayer 84132 entity. TheTaxPayer 84132 entity has a cardinality of 1 . . . 1 84134 meaning thatfor each instance of the TaxPayer 84130 package there is one TaxPayer84132 entity. The TaxPayer 84132 entity includes a TaxPayerPartyID 84136attribute. The TaxPayer 84132 entity includes an Identification 84140subordinate entity. The TaxPayerPartyID 84136 attribute has acardinality of 1 84138 meaning that for each instance of the TaxPayer84132 entity there is one TaxPayerPartyID 84136 attribute.

The Identification 84140 entity has a cardinality of 0 . . . n 84142meaning that for each instance of the TaxPayer 84132 entity there may beone or more Identification 84140 entities.

The Identification 84140 entity includes various attributes, namely aPartyIdentifierTypeCode 84144, a PartyIdentifierID 84148, anIdentifierIssuingAgencyName 84152, an EntryDate 84156, anAreaOfValidityCountryCode 84160, an AreaOfValidityRegionCode 84164 and aValidityPeriod 84168. The PartyIdentifierTypeCode 84144 attribute has acardinality of 0 . . . 1 84146 meaning that for each instance of theIdentification 84140 entity there may be one PartyIdentifierTypeCode84144 attribute. The PartyIdentifierID 84148 attribute has a cardinalityof 1 84150 meaning that for each instance of the Identification 84140entity there is one PartyIdentifierID 84148 attribute. TheIdentifierIssuingAgencyName 84152 attribute has a cardinality of 0 . . .1 84154 meaning that for each instance of the Identification 84140entity there may be one IdentifierIssuingAgencyName 84152 attribute. TheEntryDate 84156 attribute has a cardinality of 0 . . . 1 84158 meaningthat for each instance of the Identification 84140 entity there may beone EntryDate 84156 attribute. The AreaOfValidityCountryCode 84160attribute has a cardinality of 0 . . . 1 84162 meaning that for eachinstance of the Identification 84140 entity there may be oneAreaOfValidityCountryCode 84160 attribute. The AreaOfValidityRegionCode84164 attribute has a cardinality of 0 . . . 1 84166 meaning that foreach instance of the Identification 84140 entity there may be oneAreaOfValidityRegionCode 84164 attribute. The ValidityPeriod 84168attribute has a cardinality of 0 . . . 1 84170 meaning that for eachinstance of the Identification 84140 entity there may be oneValidityPeriod 84168 attribute.

The TaxPreparer 84172 package includes a TaxPreparer 84174 entity. TheTaxPreparer 84174 entity has a cardinality of 0 . . . 1 84176 meaningthat for each instance of the TaxPreparer 84172 package there may be oneTaxPreparer 84174 entity. The TaxPreparer 84174 entity includes aTaxPreparerPartyID 84178 attribute. The TaxPreparer 84174 entityincludes an Identification 84182 subordinate entity. TheTaxPreparerPartyID 84178 attribute has a cardinality of 1 84180 meaningthat for each instance of the TaxPreparer 84174 entity there is oneTaxPreparerPartyID 84178 attribute.

The Identification 84182 entity has a cardinality of 0 . . . n 84184meaning that for each instance of the TaxPreparer 84174 entity there maybe one or more Identification 84182 entities. The Identification 84182entity includes various attributes, namely a PartyIdentifierTypeCode84186, a PartyIdentifierID 84190, an IdentifierIssuingAgencyName 84194,an EntryDate 84198, an AreaOfValidityCountryCode 84202, anAreaOfValidityRegionCode 84206 and a ValidityPeriod 84210. ThePartyIdentifierTypeCode 84186 attribute has a cardinality of 0 . . . 184188 meaning that for each instance of the Identification 84182 entitythere may be one PartyIdentifierTypeCode 84186 attribute. ThePartyIdentifierID 84190 attribute has a cardinality of 1 84192 meaningthat for each instance of the Identification 84182 entity there is onePartyIdentifierID 84190 attribute. The IdentifierIssuingAgencyName 84194attribute has a cardinality of 0 . . . 1 84196 meaning that for eachinstance of the Identification 84182 entity there may be oneIdentifierIssuingAgencyName 84194 attribute. The EntryDate 84198attribute has a cardinality of 0 . . . 1 84200 meaning that for eachinstance of the Identification 84182 entity there may be one EntryDate84198 attribute. The AreaOfValidityCountryCode 84202 attribute has acardinality of 0 . . . 1 84204 meaning that for each instance of theIdentification 84182 entity there may be one AreaOfValidityCountryCode84202 attribute. The AreaOfValidityRegionCode 84206 attribute has acardinality of 0 . . . 1 84208 meaning that for each instance of theIdentification 84182 entity there may be one AreaOfValidityRegionCode84206 attribute. The ValidityPeriod 84210 attribute has a cardinality of0 . . . 1 84212 meaning that for each instance of the Identification84182 entity there may be one ValidityPeriod 84210 attribute.

The JointFiler 84214 package includes a JointFiler 84216 entity. TheJointFiler 84216 entity has a cardinality of 0 . . . 1 84218 meaningthat for each instance of the JointFiler 84214 package there may be oneJointFiler 84216 entity. The JointFiler 84216 entity includes aJointFilerPartyID 84220 attribute. The JointFiler 84216 entity includesan Identification 84224 subordinate entity. The JointFilerPartyID 84220attribute has a cardinality of 1 84222 meaning that for each instance ofthe JointFiler 84216 entity there is one JointFilerPartyID 84220attribute.

The Identification 84224 entity has a cardinality of 0 . . . n 84226meaning that for each instance of the JointFiler 84216 entity there maybe one or more Identification 84224 entities. The Identification 84224entity includes various attributes, namely a PartyIdentifierTypeCode84228, a PartyIdentifierID 84232, an IdentifierIssuingAgencyName 84236,an EntryDate 84240, an AreaOfValidityCountryCode 84244, anAreaOfValidityRegionCode 84248 and a ValidityPeriod 84252. ThePartyIdentifierTypeCode 84228 attribute has a cardinality of 0 . . . 184230 meaning that for each instance of the Identification 84224 entitythere may be one PartyIdentifierTypeCode 84228 attribute. ThePartyIdentifierID 84232 attribute has a cardinality of 1 84234 meaningthat for each instance of the Identification 84224 entity there is onePartyIdentifierID 84232 attribute. The IdentifierIssuingAgencyName 84236attribute has a cardinality of 0 . . . 1 84238 meaning that for eachinstance of the Identification 84224 entity there may be oneIdentifierIssuingAgencyName 84236 attribute. The EntryDate 84240attribute has a cardinality of 0 . . . 1 84242 meaning that for eachinstance of the Identification 84224 entity there may be one EntryDate84240 attribute. The AreaOfValidityCountryCode 84244 attribute has acardinality of 0 . . . 1 84246 meaning that for each instance of theIdentification 84224 entity there may be one AreaOfValidityCountryCode84244 attribute. The AreaOfValidityRegionCode 84248 attribute has acardinality of 0 . . . 1 84250 meaning that for each instance of theIdentification 84224 entity there may be one AreaOfValidityRegionCode84248 attribute. The ValidityPeriod 84252 attribute has a cardinality of0 . . . 1 84254 meaning that for each instance of the Identification84224 entity there may be one ValidityPeriod 84252 attribute.

The Log 84256 package includes a Log 84258 entity. The Log 84258 entityhas a cardinality of 1 84260 meaning that for each instance of the Log84256 package there is one Log 84258 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 76.

In further detail, FIGS. 85-1 through 85-4 illustrate an exampleconfiguration of an Element Structure that includes aTaxReturnERPChangeRequestMessage_Sync 85000 package. TheTaxReturnERPChangeRequestMessage_Sync 85000 package includes aTaxReturnERPChangeRequestMessage_Sync 85002 entity. TheTaxReturnERPChangeRequestMessage_Sync 85000 package includes variouspackages, namely a MessageHeader 85004 and a TaxReturn 85010.

The MessageHeader 85004 package includes a MessageHeader 85006 entity.The MessageHeader 85006 entity has a cardinality of 1 85008 meaning thatfor each instance of the MessageHeader 85004 package there is oneMessageHeader 85006 entity.

The TaxReturn 85010 package includes a TaxReturn 85012 entity. TheTaxReturn 85010 package includes various packages, namely a Form 85044,a TaxPayer 85080, a TaxPreparer 85090 and a JointFiler 85100.

The TaxReturn 85012 entity has a cardinality of 1 85014 meaning that foreach instance of the TaxReturn 85010 package there is one TaxReturn85012 entity. The TaxReturn 85012 entity includes various attributes,namely an @formListCompleteTransmissionIndicator 85016, a TaxReturnID85020, a LevyTypeCode 85024, a ContractAccountID 85028, aPeriodAssignmentCode 85032, a TaxObligationID 85036 and a DraftIndicator85040. The @formListCompleteTransmissionIndicator 85016 attribute has acardinality of 0 . . . 1 85018 meaning that for each instance of theTaxReturn 85012 entity there may be one@formListCompleteTransmissionIndicator 85016 attribute. The TaxReturnID85020 attribute has a cardinality of 1 85022 meaning that for eachinstance of the TaxReturn 85012 entity there is one TaxReturnID 85020attribute. The LevyTypeCode 85024 attribute has a cardinality of 1 85026meaning that for each instance of the TaxReturn 85012 entity there isone LevyTypeCode 85024 attribute. The ContractAccountID 85028 attributehas a cardinality of 0 . . . 1 85030 meaning that for each instance ofthe TaxReturn 85012 entity there may be one ContractAccountID 85028attribute. The PeriodAssignmentCode 85032 attribute has a cardinality of1 85034 meaning that for each instance of the TaxReturn 85012 entitythere is one PeriodAssignmentCode 85032 attribute. The TaxObligationID85036 attribute has a cardinality of 1 85038 meaning that for eachinstance of the TaxReturn 85012 entity there is one TaxObligationID85036 attribute. The DraftIndicator 85040 attribute has a cardinality of0 . . . 1 85042 meaning that for each instance of the TaxReturn 85012entity there may be one DraftIndicator 85040 attribute.

The Form 85044 package includes a Form 85046 entity. The Form 85044package includes a PropertyValuation 85070 package.

The Form 85046 entity has a cardinality of 1 . . . n 85048 meaning thatfor each instance of the Form 85044 package there are one or more Form85046 entities. The Form 85046 entity includes various attributes,namely an @propertyGroupListCompleteTransmissionIndicator 85050, an@actionCode 85054, a FormUUID 85058, a FormTemplateID 85062 and aFormVersionID 85066. The @propertyGroupListCompleteTransmissionIndicator85050 attribute has a cardinality of 0 . . . 1 85052 meaning that foreach instance of the Form 85046 entity there may be one@propertyGroupListCompleteTransmissionIndicator 85050 attribute. The@actionCode 85054 attribute has a cardinality of 0 . . . 1 85056 meaningthat for each instance of the Form 85046 entity there may be one@actionCode 85054 attribute. The FormUUID 85058 attribute has acardinality of 0 . . . 1 85060 meaning that for each instance of theForm 85046 entity there may be one FormUUID 85058 attribute. TheFormTemplateID 85062 attribute has a cardinality of 1 85064 meaning thatfor each instance of the Form 85046 entity there is one FormTemplateID85062 attribute. The FormVersionID 85066 attribute has a cardinality of1 85068 meaning that for each instance of the Form 85046 entity there isone FormVersionID 85066 attribute.

The PropertyValuation 85070 package includes a PropertyValuation 85072entity. The PropertyValuation 85072 entity has a cardinality of 0 . . .1 85074 meaning that for each instance of the PropertyValuation 85070package there may be one PropertyValuation 85072 entity. ThePropertyValuation 85072 entity includes a PropertyValuation 85076attribute. The PropertyValuation 85076 attribute has a cardinality of 1. . . n 85078 meaning that for each instance of the PropertyValuation85072 entity there are one or more PropertyValuation 85076 attributes.

The TaxPayer 85080 package includes a TaxPayer 85082 entity. TheTaxPayer 85082 entity has a cardinality of 1 . . . 1 85084 meaning thatfor each instance of the TaxPayer 85080 package there is one TaxPayer85082 entity. The TaxPayer 85082 entity includes a TaxPayerPartyID 85086attribute. The TaxPayerPartyID 85086 attribute has a cardinality of 185088 meaning that for each instance of the TaxPayer 85082 entity thereis one TaxPayerPartyID 85086 attribute.

The TaxPreparer 85090 package includes a TaxPreparer 85092 entity. TheTaxPreparer 85092 entity has a cardinality of 0 . . . 1 85094 meaningthat for each instance of the TaxPreparer 85090 package there may be oneTaxPreparer 85092 entity. The TaxPreparer 85092 entity includes aTaxPreparerPartyID 85096 attribute. The TaxPreparerPartyID 85096attribute has a cardinality of 1 85098 meaning that for each instance ofthe TaxPreparer 85092 entity there is one TaxPreparerPartyID 85096attribute.

The JointFiler 85100 package includes a JointFiler 85102 entity. TheJointFiler 85102 entity has a cardinality of 0 . . . 1 85104 meaningthat for each instance of the JointFiler 85100 package there may be oneJointFiler 85102 entity. The JointFiler 85102 entity includes aJointFilerPartyID 85106 attribute. The JointFilerPartyID 85106 attributehas a cardinality of 1 85108 meaning that for each instance of theJointFiler 85102 entity there is one JointFilerPartyID 85106 attribute.The data types of the various packages, entities, and attributes aredescribed with respect to FIG. 76.

In further detail, FIGS. 86-1 through 86-10 illustrate an exampleconfiguration of an Element Structure that includes aTaxReturnERPChangeConfirmationMessage_Sync 86000 package. TheTaxReturnERPChangeConfirmationMessage_Sync 86000 package includes aTaxReturnERPChangeConfirmationMessage_Sync 86002 entity. TheTaxReturnERPChangeConfirmationMessage_Sync 86000 package includesvarious packages, namely a MessageHeader 86004, a TaxReturn 86010 and aLog 86250.

The MessageHeader 86004 package includes a MessageHeader 86006 entity.The MessageHeader 86006 entity has a cardinality of 0 . . . 1 86008meaning that for each instance of the MessageHeader 86004 package theremay be one MessageHeader 86006 entity.

The TaxReturn 86010 package includes a TaxReturn 86012 entity. TheTaxReturn 86010 package includes various packages, namely a Form 86084,a TaxPayer 86124, a TaxPreparer 86166 and a JointFiler 86208.

The TaxReturn 86012 entity has a cardinality of 1 86014 meaning that foreach instance of the TaxReturn 86010 package there is one TaxReturn86012 entity. The TaxReturn 86012 entity includes various attributes,namely a TaxReturnID 86016, a LevyTypeCode 86020, a LevyTypeCodeName86024, a ContractAccountID 86028, a PeriodAssignmentCode 86032, aPeriodAssignmentCodeName 86036, a TaxObligationID 86040 and aDraftIndicator 86080. The TaxReturn 86012 entity includes varioussubordinate entities, namely a SystemStatus 86044 and a UserStatus86068. The TaxReturnID 86016 attribute has a cardinality of 1 86018meaning that for each instance of the TaxReturn 86012 entity there isone TaxReturnID 86016 attribute. The LevyTypeCode 86020 attribute has acardinality of 1 86022 meaning that for each instance of the TaxReturn86012 entity there is one LevyTypeCode 86020 attribute. TheLevyTypeCodeName 86024 attribute has a cardinality of 0 . . . 1 86026meaning that for each instance of the TaxReturn 86012 entity there maybe one LevyTypeCodeName 86024 attribute. The ContractAccountID 86028attribute has a cardinality of 0 . . . 1 86030 meaning that for eachinstance of the TaxReturn 86012 entity there may be oneContractAccountID 86028 attribute.

The PeriodAssignmentCode 86032 attribute has a cardinality of 1 86034meaning that for each instance of the TaxReturn 86012 entity there isone PeriodAssignmentCode 86032 attribute. The PeriodAssignmentCodeName86036 attribute has a cardinality of 0 . . . 1 86038 meaning that foreach instance of the TaxReturn 86012 entity there may be onePeriodAssignmentCodeName 86036 attribute. The TaxObligationID 86040attribute has a cardinality of 1 86042 meaning that for each instance ofthe TaxReturn 86012 entity there is one TaxObligationID 86040 attribute.The DraftIndicator 86080 attribute has a cardinality of 1 86082 meaningthat for each instance of the TaxReturn 86012 entity there is oneDraftIndicator 86080 attribute.

The SystemStatus 86044 entity has a cardinality of 1 . . . n 86046meaning that for each instance of the TaxReturn 86012 entity there areone or more SystemStatus 86044 entities. The SystemStatus 86044 entityincludes various attributes, namely a SystemStatusCode 86048, aSystemStatusCodeName 86052, an Activelndicator 86056, a ChangeTimePoint86060 and a ProcessorPartyInternalID 86064. The SystemStatusCode 86048attribute has a cardinality of 1 86050 meaning that for each instance ofthe SystemStatus 86044 entity there is one SystemStatusCode 86048attribute. The SystemStatusCodeName 86052 attribute has a cardinality of0 . . . 1 86054 meaning that for each instance of the SystemStatus 86044entity there may be one SystemStatusCodeName 86052 attribute. TheActivelndicator 86056 attribute has a cardinality of 1 86058 meaningthat for each instance of the SystemStatus 86044 entity there is oneActiveIndicator 86056 attribute. The ChangeTimePoint 86060 attribute hasa cardinality of 1 86062 meaning that for each instance of theSystemStatus 86044 entity there is one ChangeTimePoint 86060 attribute.The ProcessorPartyInternalID 86064 attribute has a cardinality of 186066 meaning that for each instance of the SystemStatus 86044 entitythere is one ProcessorPartyInternalID 86064 attribute.

The UserStatus 86068 entity has a cardinality of 0 . . . n 86070 meaningthat for each instance of the TaxReturn 86012 entity there may be one ormore UserStatus 86068 entities. The UserStatus 86068 entity includesvarious attributes, namely a UserStatusCode 86072 and aUserStatusCodeName 86076. The UserStatusCode 86072 attribute has acardinality of 1 86074 meaning that for each instance of the UserStatus86068 entity there is one UserStatusCode 86072 attribute. TheUserStatusCodeName 86076 attribute has a cardinality of 0 . . . 1 86078meaning that for each instance of the UserStatus 86068 entity there maybe one UserStatusCodeName 86076 attribute.

The Form 86084 package includes a Form 86086 entity. The Form 86084package includes a PropertyValuation 86114 package.

The Form 86086 entity has a cardinality of 0 . . . n 86088 meaning thatfor each instance of the Form 86084 package there may be one or moreForm 86086 entities. The Form 86086 entity includes various attributes,namely a FormUUID 86090, a FormTemplateID 86094, a FormTemplateName86098, a FormVersionID 86102, a FormTypeCode 86106 and aFormTypeCodeName 86110. The FormUUID 86090 attribute has a cardinalityof 1 86092 meaning that for each instance of the Form 86086 entity thereis one FormUUID 86090 attribute. The FormTemplateID 86094 attribute hasa cardinality of 1 86096 meaning that for each instance of the Form86086 entity there is one FormTemplateID 86094 attribute. TheFormTemplateName 86098 attribute has a cardinality of 0 . . . 1 86100meaning that for each instance of the Form 86086 entity there may be oneFormTemplateName 86098 attribute. The FormVersionID 86102 attribute hasa cardinality of 1 86104 meaning that for each instance of the Form86086 entity there is one FormVersionID 86102 attribute. TheFormTypeCode 86106 attribute has a cardinality of 1 86108 meaning thatfor each instance of the Form 86086 entity there is one FormTypeCode86106 attribute. The FormTypeCodeName 86110 attribute has a cardinalityof 0 . . . 1 86112 meaning that for each instance of the Form 86086entity there may be one FormTypeCodeName 86110 attribute.

The PropertyValuation 86114 package includes a PropertyValuation 86116entity. The PropertyValuation 86116 entity has a cardinality of 0 . . .1 86118 meaning that for each instance of the PropertyValuation 86114package there may be one PropertyValuation 86116 entity. ThePropertyValuation 86116 entity includes a PropertyValuation 86120attribute. The PropertyValuation 86120 attribute has a cardinality of 1. . . n 86122 meaning that for each instance of the PropertyValuation86116 entity there are one or more PropertyValuation 86120 attributes.

The TaxPayer 86124 package includes a TaxPayer 86126 entity. TheTaxPayer 86126 entity has a cardinality of 1 . . . 1 86128 meaning thatfor each instance of the TaxPayer 86124 package there is one TaxPayer86126 entity. The TaxPayer 86126 entity includes a TaxPayerPartyID 86130attribute. The TaxPayer 86126 entity includes an Identification 86134subordinate entity. The TaxPayerPartyID 86130 attribute has acardinality of 1 86132 meaning that for each instance of the TaxPayer86126 entity there is one TaxPayerPartyID 86130 attribute.

The Identification 86134 entity has a cardinality of 0 . . . n 86136meaning that for each instance of the TaxPayer 86126 entity there may beone or more Identification 86134 entities. The Identification 86134entity includes various attributes, namely a PartyIdentifierTypeCode86138, a PartyIdentifierID 86142, an IdentifierIssuingAgencyName 86146,an EntryDate 86150, an AreaOfValidityCountryCode 86154, anAreaOfValidityRegionCode 86158 and a ValidityPeriod 86162. ThePartyIdentifierTypeCode 86138 attribute has a cardinality of 1 86140meaning that for each instance of the Identification 86134 entity thereis one PartyIdentifierTypeCode 86138 attribute. The PartyIdentifierID86142 attribute has a cardinality of 1 86144 meaning that for eachinstance of the Identification 86134 entity there is onePartyIdentifierID 86142 attribute. The IdentifierIssuingAgencyName 86146attribute has a cardinality of 0 . . . 1 86148 meaning that for eachinstance of the Identification 86134 entity there may be oneIdentifierIssuingAgencyName 86146 attribute. The EntryDate 86150attribute has a cardinality of 0 . . . 1 86152 meaning that for eachinstance of the Identification 86134 entity there may be one EntryDate86150 attribute. The AreaOfValidityCountryCode 86154 attribute has acardinality of 0 . . . 1 86156 meaning that for each instance of theIdentification 86134 entity there may be one AreaOfValidityCountryCode86154 attribute. The AreaOfValidityRegionCode 86158 attribute has acardinality of 0 . . . 1 86160 meaning that for each instance of theIdentification 86134 entity there may be one AreaOfValidityRegionCode86158 attribute. The ValidityPeriod 86162 attribute has a cardinality of0 . . . 1 86164 meaning that for each instance of the Identification86134 entity there may be one ValidityPeriod 86162 attribute.

The TaxPreparer 86166 package includes a TaxPreparer 86168 entity. TheTaxPreparer 86168 entity has a cardinality of 0 . . . 1 86170 meaningthat for each instance of the TaxPreparer 86166 package there may be oneTaxPreparer 86168 entity. The TaxPreparer 86168 entity includes aTaxPreparerPartyID 86172 attribute. The TaxPreparer 86168 entityincludes an Identification 86176 subordinate entity. TheTaxPreparerPartyID 86172 attribute has a cardinality of 1 86174 meaningthat for each instance of the TaxPreparer 86168 entity there is oneTaxPreparerPartyID 86172 attribute.

The Identification 86176 entity has a cardinality of 0 . . . n 86178meaning that for each instance of the TaxPreparer 86168 entity there maybe one or more Identification 86176 entities. The Identification 86176entity includes various attributes, namely a PartyIdentifierTypeCode86180, a PartyIdentifierID 86184, an IdentifierIssuingAgencyName 86188,an EntryDate 86192, an AreaOfValidityCountryCode 86196, anAreaOfValidityRegionCode 86200 and a ValidityPeriod 86204. ThePartyIdentifierTypeCode 86180 attribute has a cardinality of 1 86182meaning that for each instance of the Identification 86176 entity thereis one PartyIdentifierTypeCode 86180 attribute. The PartyIdentifierID86184 attribute has a cardinality of 1 86186 meaning that for eachinstance of the Identification 86176 entity there is onePartyIdentifierID 86184 attribute. The IdentifierIssuingAgencyName 86188attribute has a cardinality of 0 . . . 1 86190 meaning that for eachinstance of the Identification 86176 entity there may be oneIdentifierIssuingAgencyName 86188 attribute. The EntryDate 86192attribute has a cardinality of 0 . . . 1 86194 meaning that for eachinstance of the Identification 86176 entity there may be one EntryDate86192 attribute. The AreaOfValidityCountryCode 86196 attribute has acardinality of 0 . . . 1 86198 meaning that for each instance of theIdentification 86176 entity there may be one AreaOfValidityCountryCode86196 attribute. The AreaOfValidityRegionCode 86200 attribute has acardinality of 0 . . . 1 86202 meaning that for each instance of theIdentification 86176 entity there may be one AreaOfValidityRegionCode86200 attribute. The ValidityPeriod 86204 attribute has a cardinality of0 . . . 1 86206 meaning that for each instance of the Identification86176 entity there may be one ValidityPeriod 86204 attribute.

The JointFiler 86208 package includes a JointFiler 86210 entity. TheJointFiler 86210 entity has a cardinality of 0 . . . 1 86212 meaningthat for each instance of the JointFiler 86208 package there may be oneJointFiler 86210 entity. The JointFiler 86210 entity includes aJointFilerPartyID 86214 attribute. The JointFiler 86210 entity includesan Identification 86218 subordinate entity. The JointFilerPartyID 86214attribute has a cardinality of 1 86216 meaning that for each instance ofthe JointFiler 86210 entity there is one JointFilerPartyID 86214attribute.

The Identification 86218 entity has a cardinality of 0 . . . n 86220meaning that for each instance of the JointFiler 86210 entity there maybe one or more Identification 86218 entities. The Identification 86218entity includes various attributes, namely a PartyIdentifierTypeCode86222, a PartyIdentifierID 86226, an IdentifierIssuingAgencyName 86230,an EntryDate 86234, an AreaOfValidityCountryCode 86238, anAreaOfValidityRegionCode 86242 and a ValidityPeriod 86246. ThePartyIdentifierTypeCode 86222 attribute has a cardinality of 1 86224meaning that for each instance of the Identification 86218 entity thereis one PartyIdentifierTypeCode 86222 attribute. The PartyIdentifierID86226 attribute has a cardinality of 1 86228 meaning that for eachinstance of the Identification 86218 entity there is onePartyIdentifierID 86226 attribute. The IdentifierIssuingAgencyName 86230attribute has a cardinality of 0 . . . 1 86232 meaning that for eachinstance of the Identification 86218 entity there may be oneIdentifierIssuingAgencyName 86230 attribute. The EntryDate 86234attribute has a cardinality of 0 . . . 1 86236 meaning that for eachinstance of the Identification 86218 entity there may be one EntryDate86234 attribute. The AreaOfValidityCountryCode 86238 attribute has acardinality of 0 . . . 1 86240 meaning that for each instance of theIdentification 86218 entity there may be one AreaOfValidityCountryCode86238 attribute. The AreaOfValidityRegionCode 86242 attribute has acardinality of 0 . . . 1 86244 meaning that for each instance of theIdentification 86218 entity there may be one AreaOfValidityRegionCode86242 attribute. The ValidityPeriod 86246 attribute has a cardinality of0 . . . 1 86248 meaning that for each instance of the Identification86218 entity there may be one ValidityPeriod 86246 attribute.

The Log 86250 package includes a Log 86252 entity. The Log 86252 entityhas a cardinality of 1 86254 meaning that for each instance of the Log86250 package there is one Log 86252 entity. The data types of thevarious packages, entities, and attributes are described with respect toFIG. 76.

A number of implementations have been described. Nevertheless, it willbe understood that various modifications may be made without departingfrom the spirit and scope of the disclosure. Accordingly, otherimplementations are within the scope of the following claims.

1. (canceled)
 2. A non-transitory computer readable medium includingprogram code for providing a message-based interface for performing atax assessment notice service, the medium comprising: program code forreceiving via a message-based interface exposing at least one service asdefined in a service registry and from a heterogeneous applicationexecuting in an environment of computer systems providing message-basedservices, a first message for querying one or more tax assessmentnotices by business partners, where each tax assessment notice comprisesa notice from a tax authority to a taxpayer stating that the taxpayerowes taxes or is due a refund, the first message derived from the commonbusiness object model and including a first message packagehierarchically organized as: a tax assessment notice enterprise resourceplanning (ERP) by business partner query message entity; and a selectionpackage, the selection package including a tax assessment noticeselection by business partner entity, the tax assessment noticeselection by business partner entity including a tax payer partyidentifier (ID), a billing period ID, and a levy type code; program codefor processing the first message according to the hierarchicalorganization of the first message package, where processing the firstmessage includes unpacking the first message package based on the commonbusiness object model; and program code for sending a second message tothe heterogeneous application responsive to the first message, where thesecond message includes a second message package derived from the commonbusiness object model to provide consistent semantics with the firstmessage package.
 3. A non-transitory computer readable medium includingprogram code for providing a message-based interface for performing atax return service in an enterprise resource planning (ERP) system, themedium comprising: program code for receiving via a message-basedinterface exposing at least one service as defined in a service registryand from a heterogeneous application executing in an environment ofcomputer systems providing message-based services, a first message forrequesting creation of a tax return in an ERP system, the tax returnincluding a person's, company's, or organization's tax details forsubmission by the taxpayer or the taxpayer's legal representative to atax authority, the first message derived from the common business objectmodel and including a first message package hierarchically organized as:a tax return ERP create request message entity; and a tax returnpackage, the tax return package including a tax return entity, a formpackage, and a tax payer package, the tax return entity including a levytype code, a period assignment code, and a tax obligation identifier(ID), the form package including at least one form entity, each formentity including a form template ID and a form version ID, the tax payerpackage including a tax payer entity, the tax payer entity including atax payer party ID; program code for processing the first messageaccording to the hierarchical organization of the first message package,where processing the first message includes unpacking the first messagepackage based on the common business object model; and program code forsending a second message to the heterogeneous application responsive tothe first message, where the second message includes a second messagepackage derived from the common business object model to provideconsistent semantics with the first message package.
 4. The computerreadable medium of claim 3, the tax return package further including atleast one of a tax preparer package and a joint filer package.
 5. Thecomputer readable medium of claim 3, wherein the form package includes aproperty valuation package, where the property valuation packageincludes a property valuation entity, where the property valuationentity includes at least one property valuation.
 6. A non-transitorycomputer readable medium including program code for providing amessage-based interface for performing a tax obligation service in anenterprise resource planning (ERP) system, the medium comprising:program code for receiving via a message-based interface exposing atleast one service as defined in a service registry and from aheterogeneous application executing in an environment of computersystems providing message-based services, a first message for requestinga change of registration information based on a tax registration formassociated with a tax obligation, the tax obligation representing alegal requirement that can be fulfilled by a taxpayer, including anobligation to file tax returns and pay taxes at defined due dates, thefirst message derived from the common business object model andincluding a first message package hierarchically organized as: a taxobligation ERP filing obligation change request message entity; and atax obligation package, the tax obligation package including a taxobligation entity and a filing obligation package, the tax obligationentity including a filing obligation list complete transmissionindicator and a tax obligation identifier (ID), the filing obligationpackage including at least one filing obligation entity, each filingobligation entity including an action code, an inbound correspondencecategory code, a billing period ID, and a billing start date; programcode for processing the first message according to the hierarchicalorganization of the first message package, where processing the firstmessage includes unpacking the first message package based on the commonbusiness object model; and program code for sending a second message tothe heterogeneous application responsive to the first message, where thesecond message includes a second message package derived from the commonbusiness object model to provide consistent semantics with the firstmessage package.
 7. The computer readable medium of claim 6, whereineach filing obligation entity includes at least one of a correspondencestatus code, an inbound correspondence due date, an inboundcorrespondence received date, an inbound correspondence deferral date, aclearing reason code, an amount, a currency code, and a correspondingtax return ID.
 8. A non-transitory computer readable medium includingprogram code for providing a message-based interface for performing atax object service in an enterprise resource planning (ERP) system, themedium comprising: program code for receiving via a message-basedinterface exposing at least one service as defined in a service registryand from a heterogeneous application executing in an environment ofcomputer systems providing message-based services, a first message forrequesting creation of a new tax object, the tax object comprising asubject of a tax assessment, the tax object including attributes whichare a basis for a tax collection, the first message derived from thecommon business object model and including a first message packagehierarchically organized as: a tax object ERP create request messageentity; and a tax object package, the tax object package including a taxobject entity and a tax obligation assignment package, the tax objectentity including a tax object name, and the tax obligation assignmentpackage including at least one tax obligation assignment entity, eachtax obligation assignment entity including a tax obligation identifier(ID); program code for processing the first message according to thehierarchical organization of the first message package, where processingthe first message includes unpacking the first message package based onthe common business object model; and program code for sending a secondmessage to the heterogeneous application responsive to the firstmessage, where the second message includes a second message packagederived from the common business object model to provide consistentsemantics with the first message package.
 9. The computer readablemedium of claim 8, wherein the tax object package includes a businesslicense assignment package, wherein the business license assignmentpackage including a business license assignment entity.
 10. The computerreadable medium of claim 8, wherein the tax object package includes aproperty group package, wherein the property group package includes atleast one property group entity.
 11. The computer readable medium ofclaim 8, wherein the tax object package includes a property valuationpackage, wherein the property valuation package includes a propertyvaluation entity, wherein the property valuation entity includes atleast one property valuation.